From bzbarsky at MIT.EDU  Sun Feb  1 08:00:14 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Sun, 01 Feb 2009 11:00:14 -0500
Subject: [whatwg] Resolving a URL
In-Reply-To: <Pine.LNX.4.62.0902010738410.14270@hixie.dreamhostps.com>
References: <C69ED12B-7570-4E59-BE2C-E7317D7DC36A@googlemail.com>
	<Pine.LNX.4.62.0902010738410.14270@hixie.dreamhostps.com>
Message-ID: <4985C70E.6000401@mit.edu>

Ian Hickson wrote:
> On Sun, 28 Dec 2008, Geoffrey Sneddon wrote:
> 
>> Step 12 replaces \ with /. IIRC WebKit does this for all URLs, not just 
>> those with a "server-based naming authority" (what's that anyway?).

RFC 2396 section 3.2 (Authority Component) says:

   Many URI schemes include a top hierarchical element for a naming
   authority, such that the namespace defined by the remainder of the
   URI is governed by that authority. This authority component is
   typically defined by an Internet-based server or a scheme-specific
   registry of naming authorities.

So this is talking about URLs whose authority component is defined by an 
internet server (host + port, in practice).

-Boris



From lachlan.hunt at lachy.id.au  Sun Feb  1 18:26:41 2009
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Mon, 02 Feb 2009 03:26:41 +0100
Subject: [whatwg] Semi-transparent content models
Message-ID: <498659E1.1060906@lachy.id.au>

Hi,
   The spec defines the semi-transparent content model, but this is no 
longer used for any elements.  Please remove this from the spec.

http://www.whatwg.org/specs/web-apps/current-work/#transparent-content-models

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


From philipp.kempgen at amooma.de  Mon Feb  2 16:14:15 2009
From: philipp.kempgen at amooma.de (Philipp Kempgen)
Date: Tue, 03 Feb 2009 01:14:15 +0100
Subject: [whatwg] 5.12.3.7 Link type "help"
Message-ID: <49878C57.5080605@amooma.de>

---cut---
5.12.3.7 Link type "help"
The help keyword may be used with link, a, and area  elements.
For link elements, it creates a hyperlink.
---cut---

Shouldn't that read "For *a* elements, it creates a hyperlink."?


   Philipp Kempgen

-- 
AMOOCON 2009, May 4-5, Rostock / Germany   ->  http://www.amoocon.de
Asterisk: http://the-asterisk-book.com - http://das-asterisk-buch.de
AMOOMA GmbH - Bachstr. 126 - 56566 Neuwied  ->  http://www.amooma.de
Gesch?ftsf?hrer: Stefan Wintermeyer, Handelsregister: Neuwied B14998
-- 


From chris at pearce.org.nz  Mon Feb  2 20:06:14 2009
From: chris at pearce.org.nz (Chris Pearce)
Date: Tue, 03 Feb 2009 17:06:14 +1300
Subject: [whatwg] Adding and removing media source elements
Message-ID: <4987C2B6.2010600@pearce.org.nz>

I want to clarify something about <media>'s child <source> element... In 
the <source> element spec [ 
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-source-element 
] it says:
> If a source element is inserted into a media element that is already 
> in a document and whose networkState is in the NETWORK_EMPTY state, 
> the user agent must queue a task that implicitly invokes the load() 
> method on the media element, and ignores any resulting exceptions.
So we only trigger a load when adding a child <source> element to a 
<media> element if the media element is in NETWORK_EMPTY networkState.

Additionally, in the spec for <media>'s src attribute [ 
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-media-src 
] it says:
> If the src attribute of a media element that is already in a document 
> and whose networkState is in the NETWORK_EMPTY state is added, 
> changed, or removed, the user agent must queue a task that implicitly 
> invokes the load() method on the media element, and ignores any 
> resulting exceptions. 
Almost the same, except that we invoke the load algorithm when the src 
is removed or changed in this case.

I have the following questions:

(1) Should removing a media element's child source element while the 
networkState is NETWORK_EMPTY cause the load() algorithm to be invoked? 
This would match the behviour of removing the media element's src 
attribute when networkState is NETWORK_EMPTY.

It seems that in order to start a load in an already loaded media 
element, you must change the src attribute or add source element 
children to the media element, and then call load() on the media 
element. Whereas when you initially create the media element, the first 
time you add the src attribute or add a child source element to the 
media element, you'll start an asynchronous load immediately.

(2) Why don't we invoke load() whenever a media element's src attribute 
or <source> children are changed, regardless of networkState? That way 
changes to the media's src/source other than the first change would have 
the same effect as first change, i.e. they'd have an immediate effect, 
causing load() to be invoked.

Thanks,
Chris Pearce.


From ian at hixie.ch  Mon Feb  2 20:44:07 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 3 Feb 2009 04:44:07 +0000 (UTC)
Subject: [whatwg] Adding and removing media source elements
In-Reply-To: <4987C2B6.2010600@pearce.org.nz>
References: <4987C2B6.2010600@pearce.org.nz>
Message-ID: <Pine.LNX.4.62.0902030441300.952@hixie.dreamhostps.com>

On Tue, 3 Feb 2009, Chris Pearce wrote:
> 
> (1) Should removing a media element's child source element while the 
> networkState is NETWORK_EMPTY cause the load() algorithm to be invoked? 
> This would match the behviour of removing the media element's src 
> attribute when networkState is NETWORK_EMPTY.

Removing a <source> element from a document can never, as far as I can 
tell, cause a resource that was previously not being considered to be 
considered. (Removing a src="" attribute can expose <source> elements that 
were previously being ignored.)


> (2) Why don't we invoke load() whenever a media element's src attribute 
> or <source> children are changed, regardless of networkState? That way 
> changes to the media's src/source other than the first change would have 
> the same effect as first change, i.e. they'd have an immediate effect, 
> causing load() to be invoked.

Doing this would cause the first file to be downloaded multiple times in a 
row, leading to excessive network usage.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From philipj at opera.com  Tue Feb  3 01:04:01 2009
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Tue, 03 Feb 2009 10:04:01 +0100
Subject: [whatwg] Adding and removing media source elements
In-Reply-To: <Pine.LNX.4.62.0902030441300.952@hixie.dreamhostps.com>
References: <4987C2B6.2010600@pearce.org.nz>
	<Pine.LNX.4.62.0902030441300.952@hixie.dreamhostps.com>
Message-ID: <op.uorp4zf4atwj1d@spock.linkoping.osa>

On Tue, 03 Feb 2009 05:44:07 +0100, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 3 Feb 2009, Chris Pearce wrote:
>>
>> (2) Why don't we invoke load() whenever a media element's src attribute
>> or <source> children are changed, regardless of networkState? That way
>> changes to the media's src/source other than the first change would have
>> the same effect as first change, i.e. they'd have an immediate effect,
>> causing load() to be invoked.
>
> Doing this would cause the first file to be downloaded multiple times in  
> a
> row, leading to excessive network usage.
>

Surely this can't be the only reason? User agents are free to  
speculatively keep the current source loading when src/source changes and  
to stop loading it only if the "current media resource" does change. That,  
and caching, should be enough.

I have always imagined that the reason for the conditioned load() is to  
not interrupt playback by fiddling with the DOM or doing something like  
v.src=v.src (although I'm quite sure that doesn't count as changing the  
attribute). However, now I can't convince myself that this makes any  
sense, since surely if you change src/source you actually do want to  
change the effective source (and load() is scheduled to run after the  
current script, so there's no risk of it being run too early).

Related, since load() is async it depends on timing whether or not

    <video id=v></video>
    <script>
     v = document.getElementById('v');
     v.src = 'test';
    </script>

causes the source 'test' to be loaded, as the network state may not be  
NETWORK_EMPTY when the src attribute is set. The same goes for adding  
source child elements of course. Yes, this is the same issue as  
http://lists.w3.org/Archives/Public/public-html/2009Jan/0103.html and  
would be resolved by calling load() unconditionally.

-- 
Philip J?genstedt
Opera Software


From scampa.giovanni at gmail.com  Tue Feb  3 12:42:33 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Tue, 3 Feb 2009 21:42:33 +0100
Subject: [whatwg] 5.12.3.7 Link type "help"
In-Reply-To: <49878C57.5080605@amooma.de>
References: <49878C57.5080605@amooma.de>
Message-ID: <65307430902031242s98dfb69t53e5f448d2e7020e@mail.gmail.com>

<a> elements are always hyperlinks, <link> can be hyperlinks or
resources. So it only makes sense for the <link> element to be
explicitly marked like this.

Giovanni

2009/2/3 Philipp Kempgen <philipp.kempgen at amooma.de>:
> ---cut---
> 5.12.3.7 Link type "help"
> The help keyword may be used with link, a, and area  elements.
> For link elements, it creates a hyperlink.
> ---cut---
>
> Shouldn't that read "For *a* elements, it creates a hyperlink."?
>
>
>   Philipp Kempgen
>
> --
> AMOOCON 2009, May 4-5, Rostock / Germany   ->  http://www.amoocon.de
> Asterisk: http://the-asterisk-book.com - http://das-asterisk-buch.de
> AMOOMA GmbH - Bachstr. 126 - 56566 Neuwied  ->  http://www.amooma.de
> Gesch?ftsf?hrer: Stefan Wintermeyer, Handelsregister: Neuwied B14998
> --
>


From alex.baldacchino at email.it  Tue Feb  3 15:59:12 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 04 Feb 2009 00:59:12 +0100
Subject: [whatwg] Adding and removing media source elements
In-Reply-To: <op.uorp4zf4atwj1d@spock.linkoping.osa>
References: <4987C2B6.2010600@pearce.org.nz>	<Pine.LNX.4.62.0902030441300.952@hixie.dreamhostps.com>
	<op.uorp4zf4atwj1d@spock.linkoping.osa>
Message-ID: <4988DA50.10405@email.it>

Philip J?genstedt ha scritto:
> On Tue, 03 Feb 2009 05:44:07 +0100, Ian Hickson <ian at hixie.ch> wrote:
>
>> On Tue, 3 Feb 2009, Chris Pearce wrote:
>>>
>>> (2) Why don't we invoke load() whenever a media element's src attribute
>>> or <source> children are changed, regardless of networkState? That way
>>> changes to the media's src/source other than the first change would 
>>> have
>>> the same effect as first change, i.e. they'd have an immediate effect,
>>> causing load() to be invoked.
>>
>> Doing this would cause the first file to be downloaded multiple times 
>> in a
>> row, leading to excessive network usage.
>>
>
> Surely this can't be the only reason? User agents are free to 
> speculatively keep the current source loading when src/source changes 
> and to stop loading it only if the "current media resource" does 
> change. That, and caching, should be enough.
>
> I have always imagined that the reason for the conditioned load() is 
> to not interrupt playback by fiddling with the DOM or doing something 
> like *v.src=v.src* (although I'm quite sure that doesn't count as 
> changing the attribute). However, now I can't convince myself that 
> this makes any sense, since surely if you change src/source you 
> actually do want to change the effective source (and load() is 
> scheduled to run after the current script, so there's no risk of it 
> being run too early).

Doing the same with a script element can cause the script to be 
re-fetched and re-executed on some browsers, so I think there is a 
concrete chance to find the same behaviour for videos, and the spec have 
to say when the load is allowed (or, at least, when it should not 
happen). I'm not sure that every changes to the effective source should 
take place, for instance, changing it (through the dom) after playback 
has already started might not be very usable and should be avoided, 
therefore, any such attempt should be ignored/aborted (eventually with 
an exception) after playback start and until its end or an explicit stop 
(by the user or by a script, so to encourage programmers to check the 
state of the playback before taking any action).

Also, scheduling the load "after the current script" could not solve the 
whole problem: any changes to the video may happen through an event 
handler, therefore by different scripts, thus I think that it could be 
helpful to allow a script to freeze (or revert) ongoing operations (as 
well as the video interface) but playback (if yet started), so to (try 
and) ensure (somehow) that any dynamic changes can be performed without 
bothering the user, or are disallowed otherwise.

(what for? I'm considering the (maybe edge) case of a dynamic update of 
a video source, for instance when a different/better source (higher 
quality or with a more appropriate translation) is available, or for any 
other reason (e.g. the complete list of available sources might be 
streamed as a sequence of remote events for an immediate update and a 
deferred/repeated playback), but if the current source is being played 
it might not make sense to stop it and change it with a different one, 
eventually restarting from the beginning, because it may be annoying for 
users).

>
> Related, since load() is async it depends on timing whether or not
>
>    <video id=v></video>
>    <script>
>     v = document.getElementById('v');
>     v.src = 'test';
>    </script>
>
> causes the source 'test' to be loaded, as the network state may not be 
> NETWORK_EMPTY when the src attribute is set. The same goes for adding 
> source child elements of course. Yes, this is the same issue as 
> http://lists.w3.org/Archives/Public/public-html/2009Jan/0103.html and 
> would be resolved by calling load() unconditionally.
>
Or checking the network state to choose if it's the case to call load() 
explicitely; however, due to its asynchronous nature, that might cause a 
double invocation (depending on implementations), or similar problems. 
Perhaps, the load() method should leave the network state unchanged 
(NETWORK_EMPTY in this case) or revert it to a previous value whenever 
the method fails to choose a candidate (e.g. because there is no 
valid/new source, a yet chosen source is being played and cannot be 
changed before it's stopped, and so on), and successive changes could be 
scheduled for an evaluation as soon as possible (e.g. as soon as the 
network state returns to be NETWORK_EMPTY, or becomes NETWORK_LOADED 
and/or the playback ended or has been stopped - if appropriate in this 
case), possibly being collapsed into a single task.

This way, a load evaluation preceeding the script execution, in your 
example, would fail and revert the network state to be empty, triggering 
a new invocation after the script has been executed; an evaluation 
following the script would work as expected; an evaluation invoked while 
the script is executing would cause the new v.src value to be scheduled 
for a later check, (the overall mechanism would result in an 
unconditioned scheduling of conditioned load() invocations, collapsed 
into one single entry until a call to .load() is made, which I think 
should be more performant than calling load() unconditionally - but I'm 
not sure, it may depend on both the scheduler and the load method 
implementations).

Source elements might require a different treatment from the "src" 
attribute. For instance, adding such an element while a list of 
candidates is being generated or before entering the Candidate Loop 
could cause the list to be re-checked, otherwise a delayed load is 
scheduled (but this could add unneeded complexity, thus just scheduling 
the change for a later evaluation could be enough).

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Blu American Express: gratuita a vita! 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8613&d=4-2


From alex.baldacchino at email.it  Tue Feb  3 19:15:42 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 04 Feb 2009 04:15:42 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <496BC0B6.2060906@googlemail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan>	<4966AE40.3040600@email.it>	<2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>
	<49695EA4.1060302@email.it> <4969BED3.9010401@googlemail.com>
	<496A23D8.9090901@email.it> <496A28D6.90104@googlemail.com>
	<496BA788.1030206@email.it> <496BC0B6.2060906@googlemail.com>
Message-ID: <4989085E.5040709@email.it>

Benjamin Hawkes-Lewis ha scritto:
> On 12/1/09 20:26, Calogero Alex Baldacchino wrote:
>> I just mean that, as far as I know, there is no official standard
>> requiring UAs to support (parse and expose through the DOM) attributes
>> and elements which are not part of the HTML language but are found in
>> text/html documents.
>
> Perhaps, but then prior to HTML5, much of what practical user agents 
> must do with HTML has not been required by any official standard. ;)
>
> RFC 2854 does say that "Due to the long and distributed development of 
> HTML, current practice on the Internet includes a wide variety of HTML 
> variants. Implementors of text/html interpreters must be prepared to 
> be 'bug-compatible' with popular browsers in order to work with many 
> HTML documents available the Internet."
>
> http://tools.ietf.org/html/rfc2854
>
> HTML 4.01 does recommend that "[i]f a user agent encounters an element 
> it does not recognize, it should try to render the element's content" 
> and "[i]f a user agent encounters an attribute it does not recognize, 
> it should ignore the entire attribute specification (i.e., the 
> attribute and its value)".
>
> http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.2
>
> Clearly these suggestions are incompatible with respect to attributes; 
> AFAIK all popular UAs insert unrecognized attributes into the DOM and 
> plenty of web content depends on that behaviour.
>

Very, very true. HTML 4.01 also says the recommended behaviours are ment 
"to facilitate experimentation and interoperability between 
implementations of various versions of HTML", whereas the "specification 
does not define how conforming user agents handle general error 
conditions, including how user agents behave when they encounter 
elements, attributes, attribute values, or entities not specified in 
this document", and since "user agents may vary in how they handle error 
conditions, authors and users must not rely on specific error recovery 
behavior". I just think the last sentence defines a best practice 
everyone should follow instead of relying on a common quirk supporting 
invalid markup. However, beside something being a good or bad practice, 
there will always be authors doing whatever they please, therefore it is 
quite safe to assume UAs will always expose invalid/unrecognized 
attributes (that's unavoidable, given the need for backward compatibility).

>
> Just like proprietary elements/attributes introduced with user agent 
> behaviours (marquee, autocomplete, canvas), scripted uses of "data-*" 
> might suggest new features to be added to HTML, which would then 
> become requirements for UAs.
>
> But unlike proprietary elements/attributes introduced with user agent 
> behaviors, scripted uses of "data-*" do not impose new processing 
> requirements on UAs.
>
> Therefore, unlike proprietary elements/attributes introduced with user 
> agent behaviors, scripted uses of "data-*" impose _no_ design 
> constraints on new features.
>
> Establishing user agent behaviours with "data-*" attributes, on the 
> other hand, imposes almost as many design constraints as establishing 
> them with proprietary elements and attributes. (There's just less 
> pollution of the primary HTML "namespace".)
>
> If no RDFa was in deployment, you could argue it would be less wrong 
> (from this perspective) to abuse "data-*" than introduce new attributes.

Oh, well, I don't want to argue about that. For me the idea to use 
"data-rdfa-*" can rest in peace, since in practice it's not different 
from using RDFa attributes as they are, at least as far as they're 
handled by scripts, either client- or server-side. However I think that,

* actually it seems not to be enough clear what UAs not involved in a 
particular project should do with RDFa attributes, beside exposing their 
content for the purpose of a script elaboration, whereas a precise 
behaviour should be defined, as well as an eventual class of UAs clearly 
identified as not required to support it, and eventual caveats on 
possible problems and relative solutions, before introducing any new 
elements/attributes in a formal specification;

* actual deployment might be harmed by the use of xml namespaces in html 
serialization.

Also, I see design suggestions more than impositions. If a new (and 
proprietary/private) attribute/element/convention is convincingly 
useful/needed, it is supported by other UAs and introduced in a 
specification, otherwise, if a not enough significant number of pages 
would be broken, it might even be redefined for use with a different 
semantics. And a possible process involving data-* attributes 
would/could be experiment privately => extend the scale involving other 
people finding it useful for their needs => get it in the primary 
namespace of an official specification (discarding the "data-" part and 
any other useless parts of the experimental name), so that existing 
pages may still work with their custom scripts or easily migrate to the 
new standard (and benefit of the new default support) by running a 
simple regex.

>
> But to the extent that these attributes are already in use in 
> text/html and standardized within the "http://www.w3.org/1999/xhtml" 
> namespace, processing requirements are effectively already being 
> imposed on user agents (such as not introducing conflicting treatment 
> of the "about" attribute). All that adding user agent behaviours with 
> "data-rdfa*" attributes would do at this point is add _more_ 
> requirements, without rescuing the polluted attributes.
>

For what concerns html serialization, introducing xml namespaces (and, 
thus, xml extensibility - as a whole or partly) might be worse than 
breaking current experimentaions. Since xhtml about all W3C production 
has converged towards XML, suggesting a direction the web didn't 
embraced completely, and instead causing objections with respect to xml 
features felt as useless or unwanted by a good number of people, herein 
namespaces and extensibility, hence the need to evolve html 
serialization to address new demands without forcing a migration towards 
xml. Therefore, introducing pieces of xml inside text/html documents may 
be problematic; of course, other surrogate mechanisms might be defined 
to indicate a namespace for the sole purposes of RDFa, but this would 
rise consitence issues between html and xhtml (as reported by Henri 
Sivonen), perhaps solvable by specifing a double mechanism as working 
for xhtml (the html specific one, and the "classic" xml one), but such a 
choice might add complexity to UAs and be confusing for authors.

For what concerns XHTML, I disagree with the introduction of RDFa 
attribute into the basic namespace, and I wouldn't encourage the same in 
HTML5 spec. In first place, I think there is a possible conflict with 
respect to the "content" attribute semantics, because it now requires a 
different processing when used as an RDFa attribute and as a <meta> 
attribute associated to an "http-equiv" or a "name" value (for instance).

In second place, it might be confusing for authors and lead to the 
misconception that every xhtml 1.x processor is also capable to process 
rdfa metadata (this is a limit of namespace + dtd/schema based 
modularization, because one can define the structure of a document, but 
not "orthogonal" behaviours requiring a specific support, not covered by 
the basic document model - such as collecting rdf triples declared by 
rdfa attributes, or calling a plugin and embedding its output - however, 
defining a proper namespace, maybe including its creation date somehow, 
may suggest what to expect from UAs).

In third place, creating a different namespace would have resulted in a 
far easier introduction of RDFa attributes into other xml languages 
without having to change the language to host them (by the way, the 
xhtml namespace and a related prefix can be used, but this require a 
more specific support due to the "content" attribute issue, especially 
by UAs not supporting DTDs or schemata - that is, what should happen if 
an element were declared with both xhtml:name or xhtml:http-equiv, 
xhtml:content and xhtml:datatype, in an xml document accepting any 
attributes from external namespaces? of course, this is solvable, but 
rdfa:content, rdfa:datatype and so on would make things easier, or at 
least _cleaner_ and less confusing for authors having to understand that 
an XML and RDF processor can/must support the xhtml namespace and its 
_whole_ semantics, not just dom-related structures, but limited to RDFa 
attributes, so that no <meta> or <object> or <link> can be used hoping 
their semantics is supported, despite the support for the xhtml 
namespace...). Also there might have been fewer attributes, each one 
with a different semantic (assuming someone might not find useful to 
have a link with rel="stylesheet" representing a triple, for instance).

Of course, this is my opinion.

> > I also guess that,
>> if microformats experience (or the "realworld semantics" they claim to
>> be based on) had suggested the need to add a new element/attribute to
>> the language, a new element/attribute would have been added.
>
> I'm not really sure what you mean.
>
> (It's watching the microformats community struggle with the problem of 
> encoding machine data equivalents, for things like dates and telephone 
> number types and measurements, that persuaded me HTML5 should include 
> a generic machine data attribute, because it seems likely to me that 
> the problem will be recurrent.)
>
> -- 
> Benjamin Hawkes-Lewis

If there were a general agreement, a new element/attribute would be 
introduced as a result of a "bottom up" process (starting from 
experimentations) integrated with a "top down" community evaluation - 
for specific purposes, not generic machine exposure, I mean.

(I'm not sure a generic machine data attribute - in general, not just 
referring to rdfa - would solve that, because each new occurrence of the 
problem might require a "brand new" datatype that only newer, updated 
UAs would understand (older ones would just parse the attribute and 
provide it as a string for further elaboration by a script, at most, but 
this might not be much better than using a data-* attribute for private 
script consumption), therefore, that wouldn't be necessarily different 
than creating a new appropriate attribute/element as needed and 
providing such new feature in newer, compliant UAs).


WBR, Alex

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Blu American Express: gratuita a vita! 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8613&d=4-2


From alex.baldacchino at email.it  Tue Feb  3 19:16:05 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 04 Feb 2009 04:16:05 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <B3FA8D6C-A5E7-465F-9113-52DD48DF3E00@tobyinkster.co.uk>
References: <B3FA8D6C-A5E7-465F-9113-52DD48DF3E00@tobyinkster.co.uk>
Message-ID: <49890875.9090407@email.it>

Toby A Inkster ha scritto:
>
> Another reason the Microformat experience suggests new attributes are 
> needed for semantics is the overloading of an attribute (class) 
> previously mainly used for private convention so that it is now used 
> for public consumption.

Maybe this is true, but, personally, I prefere this approach to the 
addition of new features/attributes/elements to an official 
specification without a clear support requirement for UAs beside just 
parsing. A similar (if not stronger) argument may be raised against the 
reuse of the content attribute in the context of RDFa, which I think has 
caused a significant change with respect to its original semantics (now 
it should be shared by every element, originally it was a <meta> 
specific attribute; now it should be part of an RDF _triple_, in origin 
it was - and is still - part of a _pair_ when used in conjunction with 
the "name" attribute, and constitutes a pragma directive in conjunction 
with the "http-equiv" attribute, which is somehow closer to an XML 
processing instruction than to an RDF triple - the same applies to a 
<link> with rel="stylesheet", for instance).

> Yes, in real life, there are pages that use class="vcard" for things 
> other than encoding hCard. (They mostly use it for linking to VCF 
> files.) Incredibly, I've even come across pages that use class="vcard" 
> for non-hCard uses, *and* hCard - yes, on the same page! As the 
> Microformat/POSHformat space becomes more crowded, accidental 
> collisions in class names become ever more likely.
>

Indeed, that's a possible source of troubles. I think that's the same if 
people misused prefixes, e.g. if after merging some content from 
different documents they got a different namespace binded to a 
previously declared prefix in a scope where both namespaces are involved 
(in an xhtml document). Also, a custom script may distinguish between 
different uses of "vcard" by the mean of a further, private classname, 
or by enveloping elements in containers (divs) with proper ids, which 
may be a good solution in some cases, and not in other ones; a more 
generic parser, being specialized by design, has a chance to recognize a 
correct structure for a given format and to discard wrong informations, 
which may work fine in some cases, but not in others. As always, each 
choice has its own downsides, and what counts is the costs/benefits 
ratio; it seems that any solution not requiring to be supported has the 
lowest costs for UA implementors.

I do not doubt xml extensibility (which effectively is the base of 
curies) has its own benefits, it's flexible and suitable for a quick 
developement of custom solutions, but it's also got its own downsides, 
such as leading to a possible heavy fragmentation, being difficoult to 
understand and use for many people (who are usually fooled by the 
concept of namespaces) and thus potentially causing misuses and errors. 
It doesn't seems that xml extensibility brought more benefits than 
costs, and a proof can lay in the majority of the web not having 
followed the envisioned xml-alike evolution.

Anyway, I'm not strongly against RDFa in HTML, instead, I can be quite 
neutral (I'd live with it); I'm not convinced it is worth to add it to 
the spec at this stage and until it would be possible to establish what 
UAs must do with them beside parsing (and how to deal with namespaces 
while parsing). Also, I'm not fully convinced by the need to embed 
metadata in a page and keep them in sync with that page. For instance, 
it require that every page reporting the same informations must 
duplicate the same metadata structure, and this doesn't grant that those 
informations, in first place, are in sync with real world (some pages 
might be out-of-date, others might be up-to-date). Instead, a separate 
file containing metadata to be linked when appropriate might solve both 
the problems: it doesn't require duplicates and can have a somewhat 
versioning to keep trace of changes and to present updated 
machine-friendly information to help users visiting an outdated page 
(assuming users can trust those metadata). Of course, this solution has 
its own downsides too.

WBR, Alex

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Blu American Express: gratuita a vita! 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8615&d=4-2


From alex.baldacchino at email.it  Tue Feb  3 19:16:26 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 04 Feb 2009 04:16:26 +0100
Subject: [whatwg] What RDF does Re:  Trying to work out...
In-Reply-To: <op.unmo18akwxe0ny@c211-28-146-67.smelb2.vic.optusnet.com.au>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan> <4966AE40.3040600@email.it>
	<op.unmo18akwxe0ny@c211-28-146-67.smelb2.vic.optusnet.com.au>
Message-ID: <4989088A.1060700@email.it>

Charles McCathieNevile ha scritto:
> On Fri, 09 Jan 2009 12:54:08 +1100, Calogero Alex Baldacchino 
> <alex.baldacchino at email.it> wrote:
>
>> I admit I'm not very expert in RDF use, thus I have a few questions. 
>> Specifically, maybe I can guess the advantages when using the same 
>> (carefully modelled, and well-known) vocabulary/ies; but when two 
>> organizations develop their own vocabularies, similar yet different, 
>> to model the same kind of informations, is merging of data enough? 
>> Can a processor give more than a collection of triples, to be then 
>> interpreted basing on knowledge on the used vocabulary/ies?
>
> RDF consists of several parts. One of the key parts explains how to 
> make an RDF vocabulary self-describing in terms of other vocabularies.
>
>>  I mean, I assume my tools can extract RDF(a) data from whatever 
>> document, but my query interface is based on my own vocabulary: when 
>> I merge informations from an external vocabulary, do I need to 
>> translate one vocabulary to the other (or at least to modify the 
>> query backend, so that certain curies are recognized as representing 
>> the same concepts - e.g. to tell my software that 'foaf:name' and 
>> 'ex:someone' are equivalent, for my purposes)? If so, merging data 
>> might be the minor part of the work I need to do, with respect to 
>> non-RDF(a) metadata (that is, I'd have tools to extract and merge 
>> data anyway, and once I translated external metadata to my format, I 
>> could use my own tools to merge data), specially if the same model is 
>> used both by mine and an external organization (therefore requiring 
>> an easier translation).
>
> If a vocabulary is described, then you can do an automated translation 
> from one RDF vocabulary to another by using your original query based 
> in your original vocabulary. This is one of the strengths of RDF.
>

Certainly, this is a strong benefit. However, when comparing different 
vocabularies in depth to their basic description (if any), I guess there 
may be a chance to find vocabularies which are not described in terms of 
each other, or of a third common vocabulary, thus a translation might be 
needed anyway. This might be true for small-time users developing a 
vocabulary for internal use before starting an external partnership, or 
regardless of the partnership (sometimes, small-time users may find it 
easier/faster to "reinvent the wheel" and modify it to address evolving 
problems; potentially someone might be unable to afford an extensive 
investigation to find an existing vocabulary fulfilling his requirments, 
or to develope a new one in conjunction with a partner having similar 
but slightly different needs, and thus potentially leading to a longer 
process to mediate respective needs. In such a case, I wouldn't expect 
that such a person will look for existing, more generic vocabularies 
which can describe the new one in order to ensure the widest possible 
interchange of data - that is, until a requirement for interchange 
arises, designing a vocabulary for that might be an overengineered task, 
and once the requirement was met, addressing it with a translation or 
with a description in term of a vocabulary known to be involved (each 
time the problem recurres) might be easier/faster than engineering a 
good description once and for all).

Anyway, let's assume we're going to deal with well-described 
vocabularies. Is the automated translation a task of a parser/processor 
creating a graph of triples, or a task of a query backend? And what are 
the requirements for a UA, from this perspective? Must it just parse the 
triples and create a graph or also take care of a vocabulary 
description? Must it be a complete query backend? Must it also provide a 
query interface? How much basic or advanced must the interface be? I 
think we should answer questions like this, and try and figure out 
possible problems arising with each answer and possible related 
solutions, because the concern here should be what UAs must do with RDF 
embedded in a non-RDF (and non-XML) document.

>>  Thus, I'm thinking the most valuable benefit of using RDF/RDFa is 
>> the sureness that both parties are using the very same data model, 
>> despite the possible use of different vocabularies -- it seems to me 
>> that the concept of triples consisting of a subject, a predicate and 
>> an object is somehow similar to a many-to-many association in a 
>> database, whereas one might prefer a one-to-many approach - though, 
>> the former might be a natural choice to model data which are usually 
>> sparse, as in a document prose.
>
> I don't see the ananlogy, but yes, I think the big benefit is being 
> able to ensure that you know the data model without knowing the 
> vocabulary a priori - since this is sufficient to automate the process 
> of merging data into your model.
>

I understand the benefit with respect to well-known and/or 
well-described vocabularies, but I wonder if an average small-time user 
would produce a well-described or a very-custom vocabulary. In the 
latter case, a good knowledge of a foreing vocabulary should be needed 
before querying it and I guess the translation can't be automated, but 
requires an understanding level which might be close to the one needed 
to translate from a (more or less) different model. In this case, the 
benefit of an automated merging of data from similar models might be 
lost in front of a non-automated translation which might be as difficult 
as translating from different models (but with a sufficient verbal 
documentation - that is with a natural language description, which 
should be easier to produce than a code-level description), given that 
translated data should be easy to merge.

I'm pushing this concept because I think it should be clear what 
scenario is more likely to happen, to avoid to introduce features 
perfectly designed for the same people who can develop a "perfect" 
vocabulary with a "perfect" generic description, and I suppose to be the 
same who can afford to develop a generic toolkit on their own, or to 
adjust an existing one (thus, they might be pleased with a basic support 
and a basic API), but not for most small-time users, who might develop a 
custom vocabulary the same way they develop a custom model, thus needing 
more custom tools (again, a basic support and a basic API might satisfay 
their needs, more than a complete backend working fine with 
well-described vocabularies but not with completely unknown ones, thus 
requiring a custom developement anyway).

Assuming this is true, there should be an evidence that the same people 
who'd produce a "bad" vocabulary do not prefer a completely custom 
model, because, if they were the great majority, we would risk to invest 
resources (on the UAs side, if we made of it a general requirement) to 
help people who may be pleased with the help, but not really need it 
(because they're not small-time users maybe, and can do it on their own 
without too much effort -- this doesn't mean that their requirements are 
less significant and worth to be taken into account, but in general UA 
developers might not be very happy to invest their resources to 
implement something which is or appear overengineered with respect to 
the real needs "in the wild", thus we should carefully establish how 
strong is the need to support RDFa and accurately define support 
requirements for UAs).

> cheers
>
> Chaals
>

WBR, Alex

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Blu American Express: gratuita a vita! 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8613&d=4-2


From alex.baldacchino at email.it  Tue Feb  3 19:17:18 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 04 Feb 2009 04:17:18 +0100
Subject: [whatwg] RDFa is to structured data,
 like canvas is to bitmap and SVG is to vector
In-Reply-To: <497233D3.8000904@burningbird.net>
References: <49720D65.6060301@burningbird.net>	<3d4032300901171027l72ae0411jc6cb23a4d8748f34@mail.gmail.com>	<Pine.LNX.4.62.0901171910570.29785@hixie.dreamhostps.com>
	<497233D3.8000904@burningbird.net>
Message-ID: <498908BE.1000301@email.it>

Shelley Powers ha scritto:
>
>
> The point I'm making is that you set a precedent, and a good one I 
> think: giving precedence to "not invented here". In other words, to 
> not re-invent new ways of doing something, but to look for established 
> processes, models, et al already in place, implemented, vetted, etc, 
> that solve specific problems. Now that you have accepted a use case, 
> Martin's, and we've established that RDFa solves the problem 
> associated with the use case, the issue then becomes *is there another 
> data model already as vetted, documented, implemented that would 
> better solve the problem*.
>

RDF in a separate XML-syntax file, perhaps. Just because that use case 
raised a privacy concern on informations to keep private anyway, and 
that's not a problem solvable at the document level with metadata; 
instead, keeping relevant metadata in a separate file would help a 
better access control. Also, a separate file would have the relevant 
informations ready for use, while embedding them with other content 
would force a load and parsing of the other content in search of 
relevant metadata (possible, of course, and not much of a problem, but 
not as clean and efficient).

Moreover, it should be verified whether social-network service providers 
agree with such a requirement: I might avail of a compliant 
implementation to easily migrate from one service to another and leave 
the former, in which case why should a company open its inner 
infrastructure and database and invest resources for the benefit of a 
competitor accessing its data and consuming its bandwidth to catch its 
customers? (this is not the same interoperability issue for mail clients 
supporting different address book formats, minor vendors had to do that 
to improve their businness - and they didn't need to access a 
competitor's infrastructure).

Perhaps, that might work if personal infos and relationships were 
handled by an external service on the same lines of an OpenID service 
allowing an automated identification by other services; but this would 
reduce social networks to be a kind of front-end for such a centralized 
management (and service providers might not like that). Also, in this 
case anonimity should be ensured (for instance, I might have met you in 
two different networks, but knew your identity in only one of them, and 
you might wish that no one knew you're the person behind the other 
nickname; this is possible taking different informations in different 
databases and with different access rights, and should be replicable 
when merging such infos -- on the other hand, if you knew my identity, 
you should be allowed to "fill in the blanks" somehow).

Shelley Powers ha scritto:
> Anne van Kesteren wrote:
>> On Sun, 18 Jan 2009 17:15:34 +0100, Shelley Powers 
>> <shelleyp at burningbird.net> wrote:
>>> And regardless of the fact that I jumped to conclusions about WhatWG 
>>> membership, I do not believe I was inaccurate with the earlier part 
>>> of this email. Sam started a new thread in the discussion about the 
>>> issues of namespace and how, perhaps we could find a way to work the 
>>> issues through with RDFa. My god, I use RDFa in my pages, and they 
>>> load fine with any browser, including IE. I have to believe its 
>>> incorporation into HTML5 is not the daunting effort that others make 
>>> it seem to be.'
>>
>> You ask us to take you seriously and consider your feedback, it would 
>> be nice if you took what e.g. Henri wrote seriously as well. 
>> Integrating a new feature in HTML is not a simple task, even if the 
>> new feature loads and renders fine in Internet Explorer.
>>
> Take you guys seriously...OK, yeah.
>
> I don't doubt that the work will be challenging, or problematical. I'm 
> not denying Henri's claim. And I didn't claim to be the one who would 
> necessarily come up with the solutions, either, but that I would help 
> in those instances that I could. 

It seems that you'd expect RDFa to be specced out before solving related 
problems (so to push their solution). I don't think that's the right 
path to follow, instead known issues must be solved before making a 
decision, so that the specification can tell exactly what developers 
must implement, eventually pointing out (after/while implementing) newer 
(hopefully minor) issues to be solved by refining the spec (which is a 
different task than specifying something known to be, let's say, "buggy" 
or uncertain).


Everything, as always, IMHO

WBR, Alex


 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Blu American Express: gratuita a vita! 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8613&d=4-2


From alex.baldacchino at email.it  Tue Feb  3 19:17:59 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 04 Feb 2009 04:17:59 +0100
Subject: [whatwg] embedding meta data for copy/paste usages - possible
 use case for RDF-in-HTML?
In-Reply-To: <dd4c8a40901191843n1fbd9de7v3e0ca712b42c4c1b@mail.gmail.com>
References: <dd4c8a40901190852i55649c90l36aeadf7895d5bc9@mail.gmail.com>	<4974D2B5.3080900@lachy.id.au>
	<dd4c8a40901191843n1fbd9de7v3e0ca712b42c4c1b@mail.gmail.com>
Message-ID: <498908E7.60400@email.it>

Hallvord R M Steen ha scritto:
>   
>> HTML5 already contains elements that can be used to help obtain this
>> information, such as the <title>, <article> and it's associated heading <h1>
>> to <h6> and <time>.  Obtaining author names might be a little more
>> difficult, though perhaps hCard might help.
>>     
>
> Indeed. And it's not an either-or counter-suggestion to my proposal,
> UAs could fall back to extracting such data if more structured meta
> data is not available.
>
>   

I think that's a counter-suggestion, instead. If UAs can gather enough 
informations from existing markup, they don't need to support further 
metadata processing; if authors can put enough informations in a page 
within existing markup (or markup being introduced in current 
specification), they don't need to learn and use additional metadata to 
repeat the same informations. It seems that any additional 
metadata-related markup would add complexity to UAs (requiring support) 
but not advantages (with respect to existing solutions) in this case.

Therefore, the question moves to the format to use to move such infos to 
the clipboard, which is a different concern than embedding metadata in a 
page. Also, different use cases should lead to different formats (with 
different kind of informations taken apart in different clipboard 
entries, or binded in a sort of multipart envelop to be serialized in 
just one entry), because a generic format, addressing a lot of use 
cases, could seem overengineered to developers dealing with a specific 
use case, thus a specific format could gain support in other 
applications more easily --- third parties developers could find easier 
and more consistent to get access to the right infos in the right 
format, either by looking for a specific entry (if supported by the OS), 
or by parsing a few headers in a multipart entry looking for an offset 
associated with a mime-type (which would work without requiring support 
by OS's, but an OS could provide facilities to directly access to a 
proper section anyway; however, any support for multiple kinds of infos 
should be in scope for the OS clipbord API and/or the UA, not for a 
specific application requiring specific data - and, given the above, 
that should not be in scope for HTML5).

>>> If I copy the name of one of my Facebook "friends" and paste it into
>>> my OS address book, it would be cool if the contact information was
>>> imported automatically. Or maybe I pasted it in my webmail's address
>>> book feature, and the same import operation happened..
>>>       
>> I believe this problem is adequately addressed by the hCard microformat and
>> various browser extensions that are available for some browsers, like
>> Firefox.  The solution doesn't need to involve a copy and paste operation.
>>  It just needs a way to select contact info on the page and export it to an
>> address book.
>>     
>
> This is way more complicated for most users. Your last sentence IMO is
> not an appropriate way to use the word "just", seeing that you need to
> find and invoke an "export" command, handle files, find and invoke an
> "import" command and clear out the duplicated entries.. This is
> impossible for several users I can think of, and even for techies like
> us doing so repeatedly will eventually be a chore (even if we CAN, it
> doesn't mean that's the way we SHOULD be working).
>   

It can be improved, but it's the _best_ way to do that, and should be 
replicated in the "copy-and-paste" architecture you're proposing. 
Please, consider a basic usability principle says users should be able 
to understand what's going on basing on previous experience (that is, an 
interface have to be predictable); but users aren't confident with 
copying and pasting something different than text (in general), thus a 
UA should distinguish among a bare "copy" option, and more specific 
actions (such as "copy as quotation", "copy contact info", and so on), 
and related paste options (as needed), so that users can understand and 
choose what they want to do.

On the other hand, the same should happen in a recipient application, 
especially if providing support for different kinds of info; if either a 
UA or a recipient application (or both) provided a simple copy and a 
simple paste option (or fewer options than supported, basing on metadata 
or common markup) it could be confusing for users, nor should 
applications use metadata to choose what to do, because the user could 
just want to copy and paste some text (or do something else, but he 
knows what, so he must be free to choose it).

That is, what you're proposing is mainly addressed by moving around 
import/export features to put them into a context menu and making them 
work on a selection of text (not eliminating and substituting them with 
a "simpler" copy-paste architecture), then requiring support by other 
applications and eventually by the operative system, which is definetly 
out-of-scope for any web-related standards (we can constrain web-related 
applications to improve their interoperability with respect to 
web-related features, not generic client-only applications and/or 
operative systems to create a "brand-new" interaction and 
interoperability - and UA implementors wouldn't be happy to implement 
something they know to be incompatible with existing platforms).

> Besides, it doesn't really address the "copy ONE contact's
> information" use case well.
>
>   

Assuming social-networks service provider wanted to support it, I think 
the best way to accomplish this case is to take metadata modelling a 
contact info in a separate, non-html file, so to provide a better 
control on sensible data and enforce privacy, and to expose it as a 
linked resource, accessible with proper rights (and modified server-side 
according to lower- or heigher-level rights). For instance, a nickname 
in a page could be part of an anchor pointing to a homepage, with an 
associated context menu linking to exportable metadata. This would work 
in about every UAs: a compliant one could recognize the metadata format 
while fetching it (eg through its headers, or sniffing its content), 
copy it to the clipboard in an appropriate manner, and notify it to the 
user, or activate a proper plugin associated with a proper mime-type (or 
just ask the user what to do); a non-compliant one could just show it as 
plain text, that users could copy and paste as serialized metadata in an 
application supporting such a format, which could fit the purpose very 
well and thus be largely supported as a contact info interchange format 
(a plugin associated to a mime-type would work in this case too, as well 
as telling the user what to do - save locally, open with an external 
application, convert to something else if possible, and so on).

>   
>>> If I select an E-mail in my webmail and copy it, it would be awesome
>>> if my desktop mail client would just import the full E-mail with
>>> complete headers and different parts if I just switch to the mail
>>> client app and paste.
>>>       
>> Couldn't this be solved by the web mail server providing an export feature
>> which let the user download the email as an .eml file and open it with their
>> mail client?
>>     
>
> Of course, that or POP/IMAP access is the way things currently work.
>
>   
>> Again, I don't believe the solution to this requires a copy
>> and paste operation.
>>     
>
> ..but I think it would be more intuitive and user friendly if
> something like that worked. (Or drag-and-drop an E-mail from the
> webmail to the desktop client/file system/other webmail, which is
> basically the same thing).
>
>   

I think that drag-and-drop would work better in this case, and without 
necessarily requiring a clipboard mechanism (that is, differently from a 
copy-and-paste operation).

For instance, a webmail interface could provide a link (named ".eml 
version" or "get a copy" or "save locally" or the alike) to an eml file 
(that is, to the mail entry in a server database dynamically extracted 
and served with proper headers when queried -- this is yet done, 
somehow, by some webmails). Given that, a user would have two choices:

1) Just follow the link, so that his UA would recognize a non-html 
document and,

* open it through a plugin;
* open it through an external program;
* ask the user what to do, whithin the option to save the file locally;

this is consistent with other similar operations users are confident 
with (such as opening a pdf file), and doesn't require any particular 
further support, neither from the UA, nor from the OS, nor from the 
recipient application. Of course, the user could also right click the 
link and select "save as" (or "save target as", or whatever else it is 
labeled).

2) Drag-and-drop the link to the desktop, or to another application, so 
that either a symlink (or an "internet shortcut" or whatever else it is 
called) or a .eml file (to avoid authentication issues) is created (on 
the desktop, or in a temporary folder, as needed). This can work quite 
fine when dragging to the desktop (it should create a symlink in most 
platforms), and require a little more support to create a .eml file 
(this is yet possible on some platforms always asking what to do with a 
dragged 'object') and/or to improve direct drag-and-drop between 
applications (actually it may not work or produce the same effect as 
copying and pasting the resource address).

In the latter case (direct drag-and-drop), recipient applications could 
recognize the dragged text as a URI and try and open it the same way 
they open a local file and follow a symbolic link, thus reducing 
requirements for OS support; authentication issues could be solved by 
supporting http authentication (or a form-based challange) either in a 
library used by recipient applications, or even in a system library 
(freely implemented by an OS, without any explicit requirement), which 
could be an improvement for generic resources location and access 
(specially when dealing with symlinks), therefore possibly useful in 
other contexts than just enhancing the interoperability between a 
browser and other applications, and therefore more likely to be implemented.

The overall mechanism (normal link to a resource + normal/little 
improved drag-and-drop of the link) should work very fine in most 
platforms and fall back gracefully in other ones, both because in part 
it works fine as is, and in part it would require, globally, fewer work 
to support it than to support a copy-and-paste mechanism based on 
metadata (or an effort which could be useful in different contexts than 
just a rich copy-and-paste between applications, whereas it is 
out-of-scope for html5, and will remain such until some experimentations 
will have been made on some platforms by some UA and non-UA applications).

On the other hand, a copy-and-paste mechanism (working as if saving a 
.eml file, or just putting metadata into the clipboard) would reduce or 
eliminate authentication issues (though constraining a strong OS 
support, which is a hard goal for a web standard), but I think that's 
less usable, all things considered. Let's consider the case of a message 
containing a big attachment, such as a pdf file, which is never 
immediately downloaded by any webmails and IMAP clients: a UA could hang 
over while downloading it as the result of a copy operation, blocking 
the following paste (if not the whole OS clipboard, if locked -- not 
doing so could cause a wrong paste by a user not caring that his browser 
is still working and trying to paste something immediately hence, as 
usually possible). I think that an immediate drag-and-drop, with the 
recipient application (eventually a window manager) handling the 
download is a better solution (after all, that's what usually happens 
when opening a big file from a slow source).

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Blu American Express: gratuita a vita!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8614&d=4-2


From alex.baldacchino at email.it  Tue Feb  3 19:25:51 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 04 Feb 2009 04:25:51 +0100
Subject: [whatwg] RDFa is to structured data,
 like canvas is to bitmap and SVG is to vector
In-Reply-To: <497233D3.8000904@burningbird.net>
References: <49720D65.6060301@burningbird.net>	<3d4032300901171027l72ae0411jc6cb23a4d8748f34@mail.gmail.com>	<Pine.LNX.4.62.0901171910570.29785@hixie.dreamhostps.com>
	<497233D3.8000904@burningbird.net>
Message-ID: <49890ABF.2030801@email.it>

Shelley Powers ha scritto:
>
>
> The point I'm making is that you set a precedent, and a good one I 
> think: giving precedence to "not invented here". In other words, to 
> not re-invent new ways of doing something, but to look for established 
> processes, models, et al already in place, implemented, vetted, etc, 
> that solve specific problems. Now that you have accepted a use case, 
> Martin's, and we've established that RDFa solves the problem 
> associated with the use case, the issue then becomes *is there another 
> data model already as vetted, documented, implemented that would 
> better solve the problem*.
>

RDF in a separate XML-syntax file, perhaps. Just because that use case 
raised a privacy concern on informations to keep private anyway, and 
that's not a problem solvable at the document level with metadata; 
instead, keeping relevant metadata in a separate file would help a 
better access control. Also, a separate file would have the relevant 
informations ready for use, while embedding them with other content 
would force a load and parsing of the other content in search of 
relevant metadata (possible, of course, and not much of a problem, but 
not as clean and efficient).

Moreover, it should be verified whether social-network service providers 
agree with such a requirement: I might avail of a compliant 
implementation to easily migrate from one service to another and leave 
the former, in which case why should a company open its inner 
infrastructure and database and invest resources for the benefit of a 
competitor accessing its data and consuming its bandwidth to catch its 
customers? (this is not the same interoperability issue for mail clients 
supporting different address book formats, minor vendors had to do that 
to improve their businness - and they didn't need to access a 
competitor's infrastructure).

Perhaps, that might work if personal infos and relationships were 
handled by an external service on the same lines of an OpenID service 
allowing an automated identification by other services; but this would 
reduce social networks to be a kind of front-end for such a centralized 
management (and service providers might not like that). Also, in this 
case anonimity should be ensured (for instance, I might have met you in 
two different networks, but knew your identity in only one of them, and 
you might wish that no one knew you're the person behind the other 
nickname; this is possible taking different informations in different 
databases and with different access rights, and should be replicable 
when merging such infos -- on the other hand, if you knew my identity, 
you should be allowed to "fill in the blanks" somehow).

Shelley Powers ha scritto:
> Anne van Kesteren wrote:
>> On Sun, 18 Jan 2009 17:15:34 +0100, Shelley Powers 
>> <shelleyp at burningbird.net> wrote:
>>> And regardless of the fact that I jumped to conclusions about WhatWG 
>>> membership, I do not believe I was inaccurate with the earlier part 
>>> of this email. Sam started a new thread in the discussion about the 
>>> issues of namespace and how, perhaps we could find a way to work the 
>>> issues through with RDFa. My god, I use RDFa in my pages, and they 
>>> load fine with any browser, including IE. I have to believe its 
>>> incorporation into HTML5 is not the daunting effort that others make 
>>> it seem to be.'
>>
>> You ask us to take you seriously and consider your feedback, it would 
>> be nice if you took what e.g. Henri wrote seriously as well. 
>> Integrating a new feature in HTML is not a simple task, even if the 
>> new feature loads and renders fine in Internet Explorer.
>>
> Take you guys seriously...OK, yeah.
>
> I don't doubt that the work will be challenging, or problematical. I'm 
> not denying Henri's claim. And I didn't claim to be the one who would 
> necessarily come up with the solutions, either, but that I would help 
> in those instances that I could. 

It seems that you'd expect RDFa to be specced out before solving related 
problems (so to push their solution). I don't think that's the right 
path to follow, instead known issues must be solved before making a 
decision, so that the specification can tell exactly what developers 
must implement, eventually pointing out (after/while implementing) newer 
(hopefully minor) issues to be solved by refining the spec (which is a 
different task than specifying something known to be, let's say, "buggy" 
or uncertain).


Everything, as always, IMHO

WBR, Alex


 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Blu American Express: gratuita a vita!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8614&d=4-2


From chris at pearce.org.nz  Tue Feb  3 20:16:05 2009
From: chris at pearce.org.nz (Chris Pearce)
Date: Wed, 04 Feb 2009 17:16:05 +1300
Subject: [whatwg] Adding resourceless media to document causes error event
Message-ID: <49891685.4010104@pearce.org.nz>

I need to clarify something about the media load() algorithm [ 
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-load 
]

My reading of the spec is that if you have a media element with no src 
attribute or source element children (e.g. <video></video>) and you 
insert it into a document, then the media load() algorithm will be 
implicitly invoked, and because the list of potential media resources is 
empty, that algorithm will immediately fall through to the "failure 
step" (step 12), causing an error progress event to be dispatched to the 
media element.

My question is:

Is is really necessary to invoke the load algorithm when adding a media 
element with no src/sources to a document? Doing so just causes an error 
progress event dispatch, and we've not exactly failed to load anything, 
indeed, we've not even tried to load anything in this case.


Thanks,
Chris Pearce.


From sayrer at gmail.com  Tue Feb  3 20:48:25 2009
From: sayrer at gmail.com (Robert Sayre)
Date: Tue, 3 Feb 2009 20:48:25 -0800
Subject: [whatwg] RDFa is to structured data,
	like canvas is to bitmap and 	SVG is to vector
In-Reply-To: <4975E465.4090808@mit.edu>
References: <fb6fbf560901172032l6a197245ha054152a73ae1d46@mail.gmail.com>
	<4975E465.4090808@mit.edu>
Message-ID: <68fba5c50902032048l1c03d9e0ka25ef00ac08d5510@mail.gmail.com>

RDFa should sink or swim on its own merits, and if RDFa requires
drastic changes to HTML, it is probably broken. Let the compelling
benefits of RDFa pave the way to implementations, and then standardize
based on experience with those.

RDFa should not be blessed by HTML, and the HTML spec should adopt a
similar stance to all new features. For example, I would be very
surprised to see Web Sockets fail on its own, since the benefits seem
clear. But I could be wrong, and it should face a survival test.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."


From alex.baldacchino at email.it  Tue Feb  3 20:51:12 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Wed, 04 Feb 2009 05:51:12 +0100
Subject: [whatwg] Adding resourceless media to document causes error
	event
In-Reply-To: <49891685.4010104@pearce.org.nz>
References: <49891685.4010104@pearce.org.nz>
Message-ID: <49891EC0.80503@email.it>

Chris Pearce ha scritto:
> I need to clarify something about the media load() algorithm [ 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-load 
> ]
>
> My reading of the spec is that if you have a media element with no src 
> attribute or source element children (e.g. <video></video>) and you 
> insert it into a document, then the media load() algorithm will be 
> implicitly invoked, and because the list of potential media resources 
> is empty, that algorithm will immediately fall through to the "failure 
> step" (step 12), causing an error progress event to be dispatched to 
> the media element.
>
> My question is:
>
> Is is really necessary to invoke the load algorithm when adding a 
> media element with no src/sources to a document? Doing so just causes 
> an error progress event dispatch, and we've not exactly failed to load 
> anything, indeed, we've not even tried to load anything in this case.
>
>
> Thanks,
> Chris Pearce.

Maybe an attribute such as "enabled" (or "disabled") or "defer" or the 
alike could be helpful, so that any operations can be freezed/deferred 
whenever a DOM manipulation is needed, without caring of possible 
consequences (unless the video is being played, in which case I think 
that either manipulations should be avoided, and/or their effects 
ignored/deferred, or the playback should be explicitely stopped, e.g. by 
calling a stop() method, to force the immediate execution of a scheduled 
evaluation of new sources, eventually after the UA has asked the user 
for his permission -- I'd prefer this approach to any explicite 
invocation of the load() method, which could instead be a routine 
invoked by a task engine under certain conditions).

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Blu American Express: gratuita a vita! 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8615&d=4-2


From giovanni.gentili at gmail.com  Tue Feb  3 23:11:41 2009
From: giovanni.gentili at gmail.com (Giovanni Gentili)
Date: Wed, 4 Feb 2009 08:11:41 +0100
Subject: [whatwg] RDFa is to structured data,
	like canvas is to bitmap and 	SVG is to vector
In-Reply-To: <498908BE.1000301@email.it>
References: <49720D65.6060301@burningbird.net>
	<3d4032300901171027l72ae0411jc6cb23a4d8748f34@mail.gmail.com>
	<Pine.LNX.4.62.0901171910570.29785@hixie.dreamhostps.com>
	<497233D3.8000904@burningbird.net> <498908BE.1000301@email.it>
Message-ID: <4a30f5360902032311n75ac1eccpeb497fd37b367c51@mail.gmail.com>

Calogero Alex Baldacchino wrote:
> It seems that you'd expect RDFa to be specced out before solving related
> problems (so to push their solution). I don't think that's the right path to
> follow, instead known issues must be solved before making a decision, so
> that the specification can tell exactly what developers must implement

I think that an help in defining of the requirements around
structured data, RDFa, metadata copy&paste, semantic links [1],etc
could came from the W3C document "Use Cases and Requirements
for Ontology and API for Media Object 1.0" [2]

Take the requirements listed from "r01" to "r13" and replace
the term "media objects" with "structured/linked data".

[1] http://lists.w3.org/Archives/Public/public-html/2009Jan/0082.html
[2] http://www.w3.org/TR/2009/WD-media-annot-reqs-20090119/#req-r01
-- 
Giovanni Gentili


From bhawkeslewis at googlemail.com  Wed Feb  4 00:13:05 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Wed, 04 Feb 2009 08:13:05 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4989085E.5040709@email.it>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan>	<4966AE40.3040600@email.it>	<2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>
	<49695EA4.1060302@email.it> <4969BED3.9010401@googlemail.com>
	<496A23D8.9090901@email.it> <496A28D6.90104@googlemail.com>
	<496BA788.1030206@email.it> <496BC0B6.2060906@googlemail.com>
	<4989085E.5040709@email.it>
Message-ID: <49894E11.6080304@googlemail.com>

On 4/2/09 03:15, Calogero Alex Baldacchino wrote:
> For what concerns XHTML, I disagree with the introduction of RDFa
> attribute into the basic namespace, and I wouldn't encourage the same in
> HTML5 spec. In first place, I think there is a possible conflict with
> respect to the "content" attribute semantics, because it now requires a
> different processing when used as an RDFa attribute and as a <meta>
> attribute associated to an "http-equiv" or a "name" value (for instance).

What conflict?

1. Attributes in XHTML can be distinguished by the elements they apply 
to as well as their name (e.g. the "name" attribute).

2. In XHTML+RDFa, "content" actually means the same thing on "meta" as 
on any other element in XHTML, which is presumably why they reused that 
attribute rather than introducing a new (better-named?) one:

http://www.w3.org/TR/rdfa-syntax/#rdfa-attributes

> In second place, it might be confusing for authors and lead to the
> misconception that every xhtml 1.x processor is also capable to process
> rdfa metadata (this is a limit of namespace + dtd/schema based
> modularization, because one can define the structure of a document, but
> not "orthogonal" behaviours requiring a specific support, not covered by
> the basic document model - such as collecting rdf triples declared by
> rdfa attributes, or calling a plugin and embedding its output - however,
> defining a proper namespace, maybe including its creation date somehow,
> may suggest what to expect from UAs).

There's no way to query a user agent about support for the 
specifications associated with a particular namespace, and namespaces 
are an unreliable guide to what user agents actually support, so I don't 
buy this concern.

Existing XHTML 1.x user agents don't always implement all the features 
of XHTML 1.x (e.g. exposing "longdesc" and "cite" to the user). HTML5 is 
introducing new elements and attributes into the same namespace, and 
authors would be wrong to assume that any XHTML-supporting browser will 
know what to do with them beyond inserting them into the DOM. XHTML 
modularization means you can't count on an XHTML user agent to implement 
any particular feature in the XHTML namespace.

A more reliable guide to what user agents support is looking at the list 
of supported features (as opposed to namespaces or modules or any other 
proxy) in their documentation.

> In third place, creating a different namespace would have resulted in a
> far easier introduction of RDFa attributes into other xml languages
> without having to change the language to host them (by the way, the
> xhtml namespace and a related prefix can be used, but this require a
> more specific support due to the "content" attribute issue, especially
> by UAs not supporting DTDs or schemata - that is, what should happen if
> an element were declared with both xhtml:name or xhtml:http-equiv,
> xhtml:content and xhtml:datatype, in an xml document accepting any
> attributes from external namespaces?

I cannot understand how RDFa attributes in a different namespace would 
be easier to reuse either in another language or a XML document where 
the host is not XHTML.

"content" and "datatype" mean the same on all elements, so your 
particular example seems like a non-problem to me - at least from the 
perspective of RDFa, which doesn't define processing for "name" or 
"http-equiv".

In so far as there is a problem, it's already a problem with 
bog-standard XHTML. How should <myml:bar xhtml:name="foo" 
xhtml:http-equiv="baz" xhtml:content="quux"> be processed?

> of course, this is solvable, but
> rdfa:content, rdfa:datatype and so on would make things easier, or at
> least _cleaner_ and less confusing for authors having to understand that
> an XML and RDF processor can/must support the xhtml namespace and its
> _whole_ semantics, not just dom-related structures, but limited to RDFa
> attributes, so that no <meta> or <object> or <link> can be used hoping
> their semantics is supported, despite the support for the xhtml
> namespace...).

An "XML and RDF processor" doesn't have to support XHTML or RDFA - XML 
and RDF are independent specifications.

A conforming XHTML+RDFa UA "user agent MUST support all of the features 
required in this specification. A conforming user agent must also 
support the User Agent conformance requirements as defined in XHTML 
Modularization [XHTMLMOD] section on "XHTML Family User Agent Conformance".

http://www.w3.org/TR/rdfa-syntax/#uaconf

Those further requirements can be read at:

http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_user_agent

An XHTML+RDFa conforming user agent does not have to implement "meta", 
"object", or "link", and as a explained above, authors cannot assume 
support for particular features based on namespaces.

> Also there might have been fewer attributes, each one
> with a different semantic (assuming someone might not find useful to
> have a link with rel="stylesheet" representing a triple, for instance).

I don't follow. link with rel="stylesheet" _does_ represent information 
expressible as a triple, why would it be useful to pretend otherwise? 
And how would doing so make for fewer attributes?

> If there were a general agreement, a new element/attribute would be
> introduced as a result of a "bottom up" process (starting from
> experimentations) integrated with a "top down" community evaluation -
> for specific purposes, not generic machine exposure, I mean.

There is no general agreement to that AFAICT, and I doubt think using 
unstandardized elements or attributes or using data-* for public use 
would be good approaches to extending HTML: the former blocks potential 
extension points (e.g. "canvas") and the later pointlessly introduces 
the risk that a private use might be confused with a public one.

> (I'm not sure a generic machine data attribute - in general, not just
> referring to rdfa - would solve that, because each new occurrence of the
> problem might require a "brand new" datatype that only newer, updated
> UAs would understand (older ones would just parse the attribute and
> provide it as a string for further elaboration by a script, at most, but
> this might not be much better than using a data-* attribute for private
> script consumption), therefore, that wouldn't be necessarily different
> than creating a new appropriate attribute/element as needed and
> providing such new feature in newer, compliant UAs).

It would be very different in practice, because (like new "class" 
names), new "content" values wouldn't need to go through the W3C/WHATWG 
standards process.

That has a cost of course. You might end up with a worse design, 
especially if you don't go through a community like microformats. But 
that cost arguably isn't so bad when you're talking about embedding 
arbitrary data rather than features like "canvas" or "datagrid" that 
require new parsing, DOM APIs, and user interface from popular user 
agents. This cost appears to be acceptable in the case of microformat 
"class" names, for example. Now, you could already embed data with a bad 
design using HTML5's other extension mechanisms (e.g. "script"). It's 
just that microformats choose to abuse other attributes ("title") 
instead, partly because they allow you to wrap some human-readable 
content with its machine-readable equivalent (i.e. it's a more 
"markup-like" way of doing things). My feeling is that the cost of bad 
designs for embedded data is (1) unavoidable and (2) less than the 
benefits of avoiding misuse of other (X)HTML features for embedding data.

--
Benjamin Hawkes-Lewis


From philipj at opera.com  Wed Feb  4 01:36:18 2009
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Wed, 04 Feb 2009 10:36:18 +0100
Subject: [whatwg] Adding and removing media source elements
In-Reply-To: <4988DA50.10405@email.it>
References: <4987C2B6.2010600@pearce.org.nz>
	<Pine.LNX.4.62.0902030441300.952@hixie.dreamhostps.com>
	<op.uorp4zf4atwj1d@spock.linkoping.osa> <4988DA50.10405@email.it>
Message-ID: <op.uotmaszeatwj1d@spock.linkoping.osa>

On Wed, 04 Feb 2009 00:59:12 +0100, Calogero Alex Baldacchino  
<alex.baldacchino at email.it> wrote:

> Philip J?genstedt ha scritto:
>> On Tue, 03 Feb 2009 05:44:07 +0100, Ian Hickson <ian at hixie.ch> wrote:
>>
>>> On Tue, 3 Feb 2009, Chris Pearce wrote:
>>>>
>>>> (2) Why don't we invoke load() whenever a media element's src  
>>>> attribute
>>>> or <source> children are changed, regardless of networkState? That way
>>>> changes to the media's src/source other than the first change would  
>>>> have
>>>> the same effect as first change, i.e. they'd have an immediate effect,
>>>> causing load() to be invoked.
>>>
>>> Doing this would cause the first file to be downloaded multiple times  
>>> in a
>>> row, leading to excessive network usage.
>>>
>>
>> Surely this can't be the only reason? User agents are free to  
>> speculatively keep the current source loading when src/source changes  
>> and to stop loading it only if the "current media resource" does  
>> change. That, and caching, should be enough.
>>
>> I have always imagined that the reason for the conditioned load() is to  
>> not interrupt playback by fiddling with the DOM or doing something like  
>> *v.src=v.src* (although I'm quite sure that doesn't count as changing  
>> the attribute). However, now I can't convince myself that this makes  
>> any sense, since surely if you change src/source you actually do want  
>> to change the effective source (and load() is scheduled to run after  
>> the current script, so there's no risk of it being run too early).
>
> Doing the same with a script element can cause the script to be  
> re-fetched and re-executed on some browsers, so I think there is a  
> concrete chance to find the same behaviour for videos, and the spec have  
> to say when the load is allowed (or, at least, when it should not  
> happen). I'm not sure that every changes to the effective source should  
> take place, for instance, changing it (through the dom) after playback  
> has already started might not be very usable and should be avoided,  
> therefore, any such attempt should be ignored/aborted (eventually with  
> an exception) after playback start and until its end or an explicit stop  
> (by the user or by a script, so to encourage programmers to check the  
> state of the playback before taking any action).

I also had this "avoid accidental reloads" theory before, but it doesn't  
strike me as very reasonable after thinking more about it. Can anyone give  
an example of a use case where the DOM src attribute or <source> elements  
are added/changed "accidentally" so that it would cause an unwanted reload?

> Also, scheduling the load "after the current script" could not solve the  
> whole problem: any changes to the video may happen through an event  
> handler, therefore by different scripts, thus I think that it could be  
> helpful to allow a script to freeze (or revert) ongoing operations (as  
> well as the video interface) but playback (if yet started), so to (try  
> and) ensure (somehow) that any dynamic changes can be performed without  
> bothering the user, or are disallowed otherwise.

Just so that there is no misunderstanding, load() already is scheduled to  
run after the current script has finished. This was rather explicit in an  
earlier version of the spec and the new wording with "queue a task" should  
be taken to mean the same I assume. Perhaps it should be made explicit  
though.

> (what for? I'm considering the (maybe edge) case of a dynamic update of  
> a video source, for instance when a different/better source (higher  
> quality or with a more appropriate translation) is available, or for any  
> other reason (e.g. the complete list of available sources might be  
> streamed as a sequence of remote events for an immediate update and a  
> deferred/repeated playback), but if the current source is being played  
> it might not make sense to stop it and change it with a different one,  
> eventually restarting from the beginning, because it may be annoying for  
> users).

Can you give an example of when a script would want to change src/source  
without intending for it to cause a change of the effective source? It  
sounds like an edge case indeed and something that the spec doesn't really  
need to care about. If you really wanted to do it, construct/copy a  
HTMLMediaElement in the DOM over time (in however many event handlers you  
want) and insert/replace it into the Document when done.

>
>>
>> Related, since load() is async it depends on timing whether or not
>>
>>    <video id=v></video>
>>    <script>
>>     v = document.getElementById('v');
>>     v.src = 'test';
>>    </script>
>>
>> causes the source 'test' to be loaded, as the network state may not be  
>> NETWORK_EMPTY when the src attribute is set. The same goes for adding  
>> source child elements of course. Yes, this is the same issue as  
>> http://lists.w3.org/Archives/Public/public-html/2009Jan/0103.html and  
>> would be resolved by calling load() unconditionally.
>>
> Or checking the network state to choose if it's the case to call load()  
> explicitely; however, due to its asynchronous nature, that might cause a  
> double invocation (depending on implementations), or similar problems.  
> Perhaps, the load() method should leave the network state unchanged  
> (NETWORK_EMPTY in this case) or revert it to a previous value whenever  
> the method fails to choose a candidate (e.g. because there is no  
> valid/new source, a yet chosen source is being played and cannot be  
> changed before it's stopped, and so on), and successive changes could be  
> scheduled for an evaluation as soon as possible (e.g. as soon as the  
> network state returns to be NETWORK_EMPTY, or becomes NETWORK_LOADED  
> and/or the playback ended or has been stopped - if appropriate in this  
> case), possibly being collapsed into a single task.

Certainly it's possible to work around the current quirks in the spec by  
adding an explicit load(), but wouldn't it be better to remove the quirks  
unless there's some very compelling reason for them to be there?  
Scheduling load() after playback has ended and this type of thing just  
seems to add to the unpredictable asynchronousness of it all.

It's a big problem that the script above can cause the source 'test' to  
sometimes be loaded and sometimes not, depending on implementation and  
speed of the network. If the network stops right after the <video> tag the  
asynchronous part of load() will finish and return networkState to  
NETWORK_EMPTY. However, if the network is fast you'll likely load the  
script and run it before the asynchronous part of load() has been run,  
while networkState is NETWORK_LOADING. It's completely un-obvious to the  
casual observer that a load() might be needed in the example above, and  
script authors will make mistakes since it will work in some browsers some  
times.

> This way, a load evaluation preceeding the script execution, in your  
> example, would fail and revert the network state to be empty, triggering  
> a new invocation after the script has been executed; an evaluation  
> following the script would work as expected; an evaluation invoked while  
> the script is executing would cause the new v.src value to be scheduled  
> for a later check, (the overall mechanism would result in an  
> unconditioned scheduling of conditioned load() invocations, collapsed  
> into one single entry until a call to .load() is made, which I think  
> should be more performant than calling load() unconditionally - but I'm  
> not sure, it may depend on both the scheduler and the load method  
> implementations).
>
> Source elements might require a different treatment from the "src"  
> attribute. For instance, adding such an element while a list of  
> candidates is being generated or before entering the Candidate Loop  
> could cause the list to be re-checked, otherwise a delayed load is  
> scheduled (but this could add unneeded complexity, thus just scheduling  
> the change for a later evaluation could be enough).

The DOM can't change while the candidate list is being generated as that's  
in the synchronous part of load(). But yes, one could keep adding criteria  
for scheduling new delayed load()s and perhaps solve some of the problems.

However...

There seems to be no practical benefit from the current behavior. To the  
contrary, it (sometimes, depending on random factors) cause some rather  
unexpected behavior that requires in-depth reading of the spec to  
understand. This is our implementor experience. Instead of making the spec  
more complicated to compensate, I suggest making load() unconditional. I  
am confident that we can handle the caching issues just fine and that edge  
cases of changing src/source when you don't really want to change the  
effective source are 100% solvable by other means. In fact, there would be  
little need for an explicit load() function at all, but that's another  
issue...

-- 
Philip J?genstedt
Opera Software


From rob at sanchothefat.com  Wed Feb  4 02:13:40 2009
From: rob at sanchothefat.com (Robert O'Rourke)
Date: Wed, 04 Feb 2009 10:13:40 +0000
Subject: [whatwg] List Headers
Message-ID: <49896A54.2040607@sanchothefat.com>

Hi everyone,

Are there any plans to bring list headers from HTML3 into HTML5? They'd 
make a lot of markup patterns simpler and be very very useful when it 
comes to styling.

http://www.w3.org/MarkUp/html3/listheader.html

-Rob


From lemon at raspberry-style.net  Wed Feb  4 02:20:21 2009
From: lemon at raspberry-style.net (Christian Svindseth)
Date: Wed, 4 Feb 2009 11:20:21 +0100
Subject: [whatwg] List Headers
In-Reply-To: <49896A54.2040607@sanchothefat.com>
References: <49896A54.2040607@sanchothefat.com>
Message-ID: <6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>


On Feb 4, 2009, at 11:13 AM, Robert O'Rourke wrote:

> Hi everyone,
>
> Are there any plans to bring list headers from HTML3 into HTML5?  
> They'd make a lot of markup patterns simpler and be very very useful  
> when it comes to styling.
>
> http://www.w3.org/MarkUp/html3/listheader.html
>
> -Rob

Unless I'm misreading the spec completely, HTML5 supports h1-h6, and  
even header elements inside list items.

-Chris


From rob at sanchothefat.com  Wed Feb  4 02:23:21 2009
From: rob at sanchothefat.com (Robert O'Rourke)
Date: Wed, 04 Feb 2009 10:23:21 +0000
Subject: [whatwg] List Headers
In-Reply-To: <6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
References: <49896A54.2040607@sanchothefat.com>
	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
Message-ID: <49896C99.6000001@sanchothefat.com>

Christian Svindseth wrote:
>
> On Feb 4, 2009, at 11:13 AM, Robert O'Rourke wrote:
>
>> Hi everyone,
>>
>> Are there any plans to bring list headers from HTML3 into HTML5? 
>> They'd make a lot of markup patterns simpler and be very very useful 
>> when it comes to styling.
>>
>> http://www.w3.org/MarkUp/html3/listheader.html
>>
>> -Rob
>
> Unless I'm misreading the spec completely, HTML5 supports h1-h6, and 
> even header elements inside list items.
>
> -Chris
>

I know that, I was referring to the <lh> element ie.

<ul>
    <lh>A header for the list</lh>
    <li>List item</li>
    <li>List item</li>
    <li>List item</li>
</ul>
   


From lemon at raspberry-style.net  Wed Feb  4 02:32:33 2009
From: lemon at raspberry-style.net (Christian Svindseth)
Date: Wed, 4 Feb 2009 11:32:33 +0100
Subject: [whatwg] List Headers
In-Reply-To: <49896C99.6000001@sanchothefat.com>
References: <49896A54.2040607@sanchothefat.com>
	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
	<49896C99.6000001@sanchothefat.com>
Message-ID: <2B43703F-B681-4777-B8D4-236849026922@pha.hk>


On Feb 4, 2009, at 11:23 AM, Robert O'Rourke wrote:

>> Unless I'm misreading the spec completely, HTML5 supports h1-h6,  
>> and even header elements inside list items.
>>
>> -Chris
>>
>
> I know that, I was referring to the <lh> element ie.
>
> <ul>
>   <lh>A header for the list</lh>
>   <li>List item</li>
>   <li>List item</li>
>   <li>List item</li>
> </ul>
>

Ah, I see. Sorry about that.

My first thought is that allowing the existing header elements  
directly inside the ul would make more sense, but I could be missing  
something.

There doesn't seem to be any significant semantic difference between  
the lh element and the ones already in the spec.

-Chris


From ian at hixie.ch  Wed Feb  4 02:45:28 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Feb 2009 10:45:28 +0000 (UTC)
Subject: [whatwg] List Headers
In-Reply-To: <2B43703F-B681-4777-B8D4-236849026922@pha.hk>
References: <49896A54.2040607@sanchothefat.com>
	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
	<49896C99.6000001@sanchothefat.com>
	<2B43703F-B681-4777-B8D4-236849026922@pha.hk>
Message-ID: <Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>

On Wed, 4 Feb 2009, Robert O'Rourke wrote:
> 
> Are there any plans to bring list headers from HTML3 into HTML5? They'd 
> make a lot of markup patterns simpler and be very very useful when it 
> comes to styling.

You can do this in HTML5, using <figure> and <legend>:

   <figure>
    <legend>A header for the list</legend>
    <ul>
     <li>List item</li>
     <li>List item</li>
     <li>List item</li>
    </ul>
   </figure>

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From lachlan.hunt at lachy.id.au  Wed Feb  4 02:50:03 2009
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Wed, 04 Feb 2009 11:50:03 +0100
Subject: [whatwg] List Headers
In-Reply-To: <6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
References: <49896A54.2040607@sanchothefat.com>
	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
Message-ID: <498972DB.1060107@lachy.id.au>

Christian Svindseth wrote:
> On Feb 4, 2009, at 11:13 AM, Robert O'Rourke wrote:
>> Are there any plans to bring list headers from HTML3 into HTML5? 
>> They'd make a lot of markup patterns simpler and be very very useful 
>> when it comes to styling.
>>
>> http://www.w3.org/MarkUp/html3/listheader.html
> 
> Unless I'm misreading the spec completely, HTML5 supports h1-h6, and 
> even header elements inside list items.

While you can include headings within li elements, that's different from 
what the lh element in HTML3, or even the label element in XHTML2, were 
designed for.

I believe the use case is providing a title indicating the content of 
the list, but where the title itself shouldn't contribute to the 
document's outline.  In HTML5, the only way to do this is to precede a 
list with an heading (h1-h6) element.

As an example of this, consider the element summaries in the HTML 5 
Reference, the attribute list has the heading Attributes, but that 
heading is not meant to affect the document's outline and doesn't appear 
in the TOC.  I had to use class="no-num no-toc", which is recognised by 
anolis (the spec's pre-processor tool), to avoid it being included in 
the TOC.

http://dev.w3.org/html5/html-author/#the-elements

But note that the issue itself doesn't affect just lists.  The same 
issue occurs for the DOM Interfaces sections, but that content isn't 
marked up as a list, and I'm also considering changing the attributes to 
use a table instead of a list, providing the attributes and associated 
descriptions.

So I do not believe introducing the LH element from HTML3 would 
adequately address the use case.  It's possible that what could be 
needed is an element that can contain the heading and its associated 
content, and behaves as a sectioning root:

   "Certain elements are said to be sectioning roots, including
    blockquote and td elements. These elements can have their own
    outlines, but the sections and headers inside these elements do not
    contribute to the outlines of their ancestors."

http://www.whatwg.org/specs/web-apps/current-work/#sectioning-root

It's possible that the figure element could be used for this purpose, as 
it is already a sectioning root, in which case we wouldn't need to add 
anything new to address this use case.  Though it's not entirely clear 
to me whether the figure element's meaning allows for this case.

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


From rob at sanchothefat.com  Wed Feb  4 02:50:37 2009
From: rob at sanchothefat.com (Robert O'Rourke)
Date: Wed, 04 Feb 2009 10:50:37 +0000
Subject: [whatwg] List Headers
In-Reply-To: <2B43703F-B681-4777-B8D4-236849026922@pha.hk>
References: <49896A54.2040607@sanchothefat.com>	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>	<49896C99.6000001@sanchothefat.com>
	<2B43703F-B681-4777-B8D4-236849026922@pha.hk>
Message-ID: <498972FD.4040708@sanchothefat.com>

Christian Svindseth wrote:
>
> On Feb 4, 2009, at 11:23 AM, Robert O'Rourke wrote:
>
>>> Unless I'm misreading the spec completely, HTML5 supports h1-h6, and 
>>> even header elements inside list items.
>>>
>>> -Chris
>>>
>>
>> I know that, I was referring to the <lh> element ie.
>>
>> <ul>
>>   <lh>A header for the list</lh>
>>   <li>List item</li>
>>   <li>List item</li>
>>   <li>List item</li>
>> </ul>
>>
>
> Ah, I see. Sorry about that.
>
> My first thought is that allowing the existing header elements 
> directly inside the ul would make more sense, but I could be missing 
> something.
>
> There doesn't seem to be any significant semantic difference between 
> the lh element and the ones already in the spec.
>
> -Chris
>

No problem. It's true they're not too different but there are cases 
where you may want a heading on a list but it doesn't necessarily 
constitute a tier of the document on it's own. It's my understanding 
that <h1> - <h6> are more for structure. Perhaps if <h1> to <h6> were 
allowed immediately inside of a list it would be useful to HTML authors 
anyway but <lh> would be semantically perfect for the job and also 
provide a dicrete element away from other headers for styling. Thought 
it was worth suggesting here anyway.

-Rob


From lachlan.hunt at lachy.id.au  Wed Feb  4 03:00:26 2009
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Wed, 04 Feb 2009 12:00:26 +0100
Subject: [whatwg] List Headers
In-Reply-To: <Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
References: <49896A54.2040607@sanchothefat.com>	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>	<49896C99.6000001@sanchothefat.com>	<2B43703F-B681-4777-B8D4-236849026922@pha.hk>
	<Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
Message-ID: <4989754A.3010604@lachy.id.au>

Ian Hickson wrote:
> On Wed, 4 Feb 2009, Robert O'Rourke wrote:
>> Are there any plans to bring list headers from HTML3 into HTML5? They'd 
>> make a lot of markup patterns simpler and be very very useful when it 
>> comes to styling.
> 
> You can do this in HTML5, using <figure> and <legend>:
> 
>    <figure>
>     <legend>A header for the list</legend>
>     <ul>
>      <li>List item</li>
>      <li>List item</li>
>      <li>List item</li>
>     </ul>
>    </figure>

Since figure is a sectioning root, a heading element could also be used 
here and it wouldn't affect the outline.  Please add an example of this 
use case to the spec.

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


From rob at sanchothefat.com  Wed Feb  4 02:58:30 2009
From: rob at sanchothefat.com (Robert O'Rourke)
Date: Wed, 04 Feb 2009 10:58:30 +0000
Subject: [whatwg] List Headers
In-Reply-To: <Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
References: <49896A54.2040607@sanchothefat.com>	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>	<49896C99.6000001@sanchothefat.com>	<2B43703F-B681-4777-B8D4-236849026922@pha.hk>
	<Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
Message-ID: <498974D6.2000100@sanchothefat.com>

Ian Hickson wrote:
> On Wed, 4 Feb 2009, Robert O'Rourke wrote:
>   
>> Are there any plans to bring list headers from HTML3 into HTML5? They'd 
>> make a lot of markup patterns simpler and be very very useful when it 
>> comes to styling.
>>     
>
> You can do this in HTML5, using <figure> and <legend>:
>
>    <figure>
>     <legend>A header for the list</legend>
>     <ul>
>      <li>List item</li>
>      <li>List item</li>
>      <li>List item</li>
>     </ul>
>    </figure>
>
> HTH,
>   

Thanks Ian, and thanks to Lachlan and Christian for discussing it and 
helping to clear some things up for me.

It's going to take me a while to get used to the more creative uses of 
the new HTML5 elements!

Thanks again.
-Rob



From julian.reschke at gmx.de  Wed Feb  4 05:42:03 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed, 04 Feb 2009 14:42:03 +0100
Subject: [whatwg] List Headers
In-Reply-To: <Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
References: <49896A54.2040607@sanchothefat.com>	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>	<49896C99.6000001@sanchothefat.com>	<2B43703F-B681-4777-B8D4-236849026922@pha.hk>
	<Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
Message-ID: <49899B2B.9020506@gmx.de>

Ian Hickson wrote:
> On Wed, 4 Feb 2009, Robert O'Rourke wrote:
>> Are there any plans to bring list headers from HTML3 into HTML5? They'd 
>> make a lot of markup patterns simpler and be very very useful when it 
>> comes to styling.
> 
> You can do this in HTML5, using <figure> and <legend>:
> 
>    <figure>
>     <legend>A header for the list</legend>
>     <ul>
>      <li>List item</li>
>      <li>List item</li>
>      <li>List item</li>
>     </ul>
>    </figure>

Hm.

<http://dev.w3.org/html5/spec/Overview.html#the-figure-element>:

"The figure element represents some flow content, optionally with a 
caption, which can be moved away from the main flow of the document 
without affecting the document's meaning."

I don't think this is usually the case for a list.

BR, Julian


From rob at sanchothefat.com  Wed Feb  4 06:17:45 2009
From: rob at sanchothefat.com (Robert O'Rourke)
Date: Wed, 04 Feb 2009 14:17:45 +0000
Subject: [whatwg] List Headers
In-Reply-To: <49899B2B.9020506@gmx.de>
References: <49896A54.2040607@sanchothefat.com>	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>	<49896C99.6000001@sanchothefat.com>	<2B43703F-B681-4777-B8D4-236849026922@pha.hk>
	<Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
	<49899B2B.9020506@gmx.de>
Message-ID: <4989A389.4030500@sanchothefat.com>

Julian Reschke wrote:
> Ian Hickson wrote:
>> On Wed, 4 Feb 2009, Robert O'Rourke wrote:
>>> Are there any plans to bring list headers from HTML3 into HTML5? 
>>> They'd make a lot of markup patterns simpler and be very very useful 
>>> when it comes to styling.
>>
>> You can do this in HTML5, using <figure> and <legend>:
>>
>>    <figure>
>>     <legend>A header for the list</legend>
>>     <ul>
>>      <li>List item</li>
>>      <li>List item</li>
>>      <li>List item</li>
>>     </ul>
>>    </figure>
>
> Hm.
>
> <http://dev.w3.org/html5/spec/Overview.html#the-figure-element>:
>
> "The figure element represents some flow content, optionally with a 
> caption, which can be moved away from the main flow of the document 
> without affecting the document's meaning."
>
> I don't think this is usually the case for a list.
>
> BR, Julian
>

The BBC do it in articles all the time, little asides that are quoted in 
the story but presented in a data/extra info context to back it up.

-Rob


From bhawkeslewis at googlemail.com  Wed Feb  4 06:48:03 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Wed, 04 Feb 2009 14:48:03 +0000
Subject: [whatwg] List Headers
In-Reply-To: <49899B2B.9020506@gmx.de>
References: <49896A54.2040607@sanchothefat.com>	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>	<49896C99.6000001@sanchothefat.com>	<2B43703F-B681-4777-B8D4-236849026922@pha.hk>	<Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
	<49899B2B.9020506@gmx.de>
Message-ID: <4989AAA3.3070301@googlemail.com>

On 4/2/09 13:42, Julian Reschke wrote:
> <http://dev.w3.org/html5/spec/Overview.html#the-figure-element>:
>
> "The figure element represents some flow content, optionally with a
> caption, which can be moved away from the main flow of the document
> without affecting the document's meaning."
>
> I don't think this is usually the case for a list.

I'm not saying you're wrong, but it would help if someone could dig up 
real examples of lists that:

1. Need a label that is not a section heading.

_and_

2. Could not be moved away from the main flow of the document without 
affecting the document's meaning.

Then we could be sure we're solving a real problem.

--
Benjamin Hawkes-Lewis


From ian at hixie.ch  Wed Feb  4 11:23:04 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Feb 2009 19:23:04 +0000 (UTC)
Subject: [whatwg] List Headers
In-Reply-To: <49899B2B.9020506@gmx.de>
References: <49896A54.2040607@sanchothefat.com>
	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
	<49896C99.6000001@sanchothefat.com>
	<2B43703F-B681-4777-B8D4-236849026922@pha.hk>
	<Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
	<49899B2B.9020506@gmx.de>
Message-ID: <Pine.LNX.4.62.0902041922170.952@hixie.dreamhostps.com>

On Wed, 4 Feb 2009, Julian Reschke wrote:
> > 
> > You can do this in HTML5, using <figure> and <legend>:
> > 
> >    <figure>
> >     <legend>A header for the list</legend>
> >     <ul>
> >      <li>List item</li>
> >      <li>List item</li>
> >      <li>List item</li>
> >     </ul>
> >    </figure>
> 
> "The figure element represents some flow content, optionally with a 
> caption, which can be moved away from the main flow of the document 
> without affecting the document's meaning."
> 
> I don't think this is usually the case for a list.

As Benjamin implied, I think it actually _is_ the case for lists that have 
headers. Counter-examples would be useful though.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From dhtmlkitchen at gmail.com  Wed Feb  4 12:34:40 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 4 Feb 2009 12:34:40 -0800
Subject: [whatwg] List Headers
In-Reply-To: <Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
References: <49896A54.2040607@sanchothefat.com>
	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
	<49896C99.6000001@sanchothefat.com>
	<2B43703F-B681-4777-B8D4-236849026922@pha.hk>
	<Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
Message-ID: <c9e12660902041234j454380bfv3e3900cff94e792@mail.gmail.com>

On Wed, Feb 4, 2009 at 2:45 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 4 Feb 2009, Robert O'Rourke wrote:
>>
>> Are there any plans to bring list headers from HTML3 into HTML5? They'd
>> make a lot of markup patterns simpler and be very very useful when it
>> comes to styling.
>
> You can do this in HTML5, using <figure> and <legend>:
>
>   <figure>
>    <legend>A header for the list</legend>
>    <ul>
>     <li>List item</li>
>     <li>List item</li>
>     <li>List item</li>
>    </ul>
>   </figure>
>

The results of this example vary.

Firefox 3 adds a border around the list as a result of the legend
element. It looks as if Firefox added an anonymous "fieldset" (though
I don't know if that is what happened). Other browsers do not do that.

The figure element is used to annotate a section that could be moved
away from the main document. The <figure> element is like <section>,
but it indicates that the section can be removed from the document and
the contents will still have semantic meaning, similar to the
<article> element.

Garrett


From dhtmlkitchen at gmail.com  Wed Feb  4 12:39:41 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 4 Feb 2009 12:39:41 -0800
Subject: [whatwg] List Headers
In-Reply-To: <498972DB.1060107@lachy.id.au>
References: <49896A54.2040607@sanchothefat.com>
	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
	<498972DB.1060107@lachy.id.au>
Message-ID: <c9e12660902041239n395f3c18o1e76441049e7b03c@mail.gmail.com>

On Wed, Feb 4, 2009 at 2:50 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> Christian Svindseth wrote:
>>
>> On Feb 4, 2009, at 11:13 AM, Robert O'Rourke wrote:
>>>
>>> Are there any plans to bring list headers from HTML3 into HTML5? They'd
>>> make a lot of markup patterns simpler and be very very useful when it comes
>>> to styling.
>>>
>>> http://www.w3.org/MarkUp/html3/listheader.html
>>
>> Unless I'm misreading the spec completely, HTML5 supports h1-h6, and even
>> header elements inside list items.
>
> While you can include headings within li elements, that's different from
> what the lh element in HTML3, or even the label element in XHTML2, were
> designed for.
>
> I believe the use case is providing a title indicating the content of the
> list, but where the title itself shouldn't contribute to the document's
> outline.  In HTML5, the only way to do this is to precede a list with an
> heading (h1-h6) element.
>
> As an example of this, consider the element summaries in the HTML 5
> Reference, the attribute list has the heading Attributes, but that heading
> is not meant to affect the document's outline and doesn't appear in the TOC.
>  I had to use class="no-num no-toc", which is recognised by anolis (the
> spec's pre-processor tool), to avoid it being included in the TOC.
>
> http://dev.w3.org/html5/html-author/#the-elements
>
> But note that the issue itself doesn't affect just lists.  The same issue
> occurs for the DOM Interfaces sections, but that content isn't marked up as
> a list, and I'm also considering changing the attributes to use a table
> instead of a list, providing the attributes and associated descriptions.
>

Is this what you are referring to:-

| <h4 id="reflecting-content-attributes-in-dom-attributes"
| ><span class="secno">2.8.1 </span>Reflecting content attributes in
| DOM attributes</h4>

?

That is not marked up as a list; it uses an H4. I don't see the
similarity to the problem of wanting to have a header within a list.

The LH or element is used specifically to provide a title for a list.

The HTML 3 spec says:
| Permitted Context: Immediately following UL, OL or DL

Browsers do allow adding the lh anywhere inside the list.

Example:-

<!DOCTYPE HTML>
<html lang="en">
<head>
	<title>list header</title>
</head>
<body>
<h1>Ingredients</h1>
 <ol style="list-style-type: iroha">
   <lh>Dry:</lh>
     <li>1c flour</li>
     <li>1/4c sugar</li>
     <li>1tsp baking soda</li>
   <lh>Wet:</lh>
     <li>1 egg </li>
     <li>1/2c milk</li>
     <li>1tsp vanilla extract</li>
  </ol>
</body>
</html>

Is rendered in FF3, Saf2,3, Op 9:-
   Dry:
   1. 1c flour
   2. 1/4c sugar
   3. 1tsp baking soda
   Wet:
   4. 1 egg
   5. 1/2c milk
   6. 1tsp vanilla extract

The HTML5 <figure> element does not allow for subsections in the list.


From bzbarsky at MIT.EDU  Wed Feb  4 13:01:03 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 04 Feb 2009 16:01:03 -0500
Subject: [whatwg] List Headers
In-Reply-To: <c9e12660902041234j454380bfv3e3900cff94e792@mail.gmail.com>
References: <49896A54.2040607@sanchothefat.com>	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>	<49896C99.6000001@sanchothefat.com>	<2B43703F-B681-4777-B8D4-236849026922@pha.hk>	<Pine.LNX.4.62.0902041044150.952@hixie.dreamhostps.com>
	<c9e12660902041234j454380bfv3e3900cff94e792@mail.gmail.com>
Message-ID: <498A020F.30603@mit.edu>

Garrett Smith wrote:
> Firefox 3 adds a border around the list as a result of the legend
> element. It looks as if Firefox added an anonymous "fieldset"

It's not anonymous.  The HTML parser in Firefox actually creates a 
<fieldset> element when it encounters a <legend> that's not inside a 
<fieldset>.  You can verify this by examining the DOM.

We do plan to fix this parser issue.

-Boris


From bhawkeslewis at googlemail.com  Wed Feb  4 13:03:35 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Wed, 04 Feb 2009 21:03:35 +0000
Subject: [whatwg] List Headers
In-Reply-To: <c9e12660902041239n395f3c18o1e76441049e7b03c@mail.gmail.com>
References: <49896A54.2040607@sanchothefat.com>	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>	<498972DB.1060107@lachy.id.au>
	<c9e12660902041239n395f3c18o1e76441049e7b03c@mail.gmail.com>
Message-ID: <498A02A7.9050904@googlemail.com>

On 4/2/09 20:39, Garrett Smith wrote:
>   <ol style="list-style-type: iroha">
>     <lh>Dry:</lh>
>       <li>1c flour</li>
>       <li>1/4c sugar</li>
>       <li>1tsp baking soda</li>
>     <lh>Wet:</lh>
>       <li>1 egg</li>
>       <li>1/2c milk</li>
>       <li>1tsp vanilla extract</li>
>    </ol>

Hmm.

Does that markup solve any user problems that following traditional, 
markup does not?

    <ol style="list-style-type: iroha">
      <li class="list-header">Dry:
        <ol>
            <li>1c flour</li>
            <li>1/4c sugar</li>
            <li>1tsp baking soda</li>
        </ol>
      </li>
      <li class="list-header">Wet:
        <ol>
            <li>1 egg</li>
            <li>1/2c milk</li>
            <li>1tsp vanilla extract</li>
        </ol>
      </li>
     </ol>

Pros of lh:

* User agents could give a different default style to "LH" (e.g. bold in 
a visual medium, or reading "list header" in an speech medium).
* Fewer bytes.

Pros of traditional markup:

* Can style sublists without introducing new features to CSS.
* Works correctly in existing user agents (e.g. list navigation in 
screen readers).

--
Benjamin Hawkes-Lewis


From ian at hixie.ch  Wed Feb  4 13:04:23 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Feb 2009 21:04:23 +0000 (UTC)
Subject: [whatwg] List Headers
In-Reply-To: <c9e12660902041239n395f3c18o1e76441049e7b03c@mail.gmail.com>
References: <49896A54.2040607@sanchothefat.com>
	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
	<498972DB.1060107@lachy.id.au>
	<c9e12660902041239n395f3c18o1e76441049e7b03c@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902042103030.952@hixie.dreamhostps.com>

On Wed, 4 Feb 2009, Garrett Smith wrote:
> 
> Example:-
> 
> <!DOCTYPE HTML>
> <html lang="en">
> <head>
> 	<title>list header</title>
> </head>
> <body>
> <h1>Ingredients</h1>
>  <ol style="list-style-type: iroha">
>    <lh>Dry:</lh>
>      <li>1c flour</li>
>      <li>1/4c sugar</li>
>      <li>1tsp baking soda</li>
>    <lh>Wet:</lh>
>      <li>1 egg </li>
>      <li>1/2c milk</li>
>      <li>1tsp vanilla extract</li>
>   </ol>
> </body>
> </html>

Just use two lists in a <dl>:

  <dl>
   <dt>Dry:</dt>
   <dd>
    <ul>
     <li>1c flour</li>
     <li>1/4c sugar</li>
     <li>1tsp baking soda</li>
    </ul>
   </dd>
   <dt>Wet:</dt>
   <dd>
    <ul>
     <li>1 egg </li>
     <li>1/2c milk</li>
     <li>1tsp vanilla extract</li>
    </ul>
   </dd>
  </dl>

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Feb  4 13:11:26 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 4 Feb 2009 21:11:26 +0000 (UTC)
Subject: [whatwg] List Headers
In-Reply-To: <498A02A7.9050904@googlemail.com>
References: <49896A54.2040607@sanchothefat.com>
	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
	<498972DB.1060107@lachy.id.au>
	<c9e12660902041239n395f3c18o1e76441049e7b03c@mail.gmail.com>
	<498A02A7.9050904@googlemail.com>
Message-ID: <Pine.LNX.4.62.0902042109340.952@hixie.dreamhostps.com>

On Wed, 4 Feb 2009, Benjamin Hawkes-Lewis wrote:
> 
> Pros of lh:
> 
> * User agents could give a different default style to "LH" (e.g. bold in a
> visual medium, or reading "list header" in an speech medium).
> * Fewer bytes.
> 
> Pros of traditional markup:
> 
> * Can style sublists without introducing new features to CSS.
> * Works correctly in existing user agents (e.g. list navigation in screen
> readers).

There is also the issue that changing the parsing rules around <li> is 
difficult. For example, the following:

    <ol>
     <lh> Fruit
      <li> Apple
      <li> Pear
     <lh> Vegetables
      <li> Carrot
      <li> Celery
    </ol>

...looks like it should work, but in practice the <lh> element for 
Vegetables would end up inside the Pear <li> element, and changing that 
would likely be problematic.

Given the variety of alternatives to <lh> that already exist in HTML4 and 
that have been introduced in HTML5, I do not propose to add <lh>.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From lachlan.hunt at lachy.id.au  Wed Feb  4 13:55:44 2009
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Wed, 04 Feb 2009 22:55:44 +0100
Subject: [whatwg] List Headers
In-Reply-To: <c9e12660902041239n395f3c18o1e76441049e7b03c@mail.gmail.com>
References: <49896A54.2040607@sanchothefat.com>	
	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>	
	<498972DB.1060107@lachy.id.au>
	<c9e12660902041239n395f3c18o1e76441049e7b03c@mail.gmail.com>
Message-ID: <498A0EE0.907@lachy.id.au>

Garrett Smith wrote:
> On Wed, Feb 4, 2009 at 2:50 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
>> As an example of this, consider the element summaries in the HTML 5
>> Reference, the attribute list has the heading Attributes, but that heading
>> is not meant to affect the document's outline and doesn't appear in the TOC.
>>  I had to use class="no-num no-toc", which is recognised by anolis (the
>> spec's pre-processor tool), to avoid it being included in the TOC.
>>
>> http://dev.w3.org/html5/html-author/#the-elements
>>
>> But note that the issue itself doesn't affect just lists.  The same issue
>> occurs for the DOM Interfaces sections, but that content isn't marked up as
>> a list, and I'm also considering changing the attributes to use a table
>> instead of a list, providing the attributes and associated descriptions.
> 
> Is this what you are referring to:-
> 
> | <h4 id="reflecting-content-attributes-in-dom-attributes"
> | ><span class="secno">2.8.1 </span>Reflecting content attributes in
> | DOM attributes</h4>
> 
> ?

No, you're looking at the wrong document.  I was talking about the 
markup I used in the HTML Reference, not what's being used in the spec.

<div class="attributes">
   <h5 class="no-num no-toc" id="attributes-1">Attributes</h5>
   <ul>
     <li><span>Global attributes</span></li>
     ...
   </ul>
</div>

<div class="dom">
   <h5 class="no-num no-toc" id="dom-interface-2">DOM Interface</h5>
   <ul>
     <li>
       <pre class="idl">interface ... {
...
};</pre>
     </li>
   </ul>
</div>

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


From derernst at gmx.ch  Thu Feb  5 00:18:03 2009
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 05 Feb 2009 09:18:03 +0100
Subject: [whatwg] List Headers
In-Reply-To: <498A02A7.9050904@googlemail.com>
References: <49896A54.2040607@sanchothefat.com>	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>	<498972DB.1060107@lachy.id.au>	<c9e12660902041239n395f3c18o1e76441049e7b03c@mail.gmail.com>
	<498A02A7.9050904@googlemail.com>
Message-ID: <498AA0BB.9030501@gmx.ch>

Benjamin Hawkes-Lewis schrieb:
> On 4/2/09 20:39, Garrett Smith wrote:
>>   <ol style="list-style-type: iroha">
>>     <lh>Dry:</lh>
>>       <li>1c flour</li>
>>       <li>1/4c sugar</li>
>>       <li>1tsp baking soda</li>
>>     <lh>Wet:</lh>
>>       <li>1 egg</li>
>>       <li>1/2c milk</li>
>>       <li>1tsp vanilla extract</li>
>>    </ol>
> 
> Hmm.
> 
> Does that markup solve any user problems that following traditional, 
> markup does not?
> 
>    <ol style="list-style-type: iroha">
>      <li class="list-header">Dry:
>        <ol>
>            <li>1c flour</li>
>            <li>1/4c sugar</li>
>            <li>1tsp baking soda</li>
>        </ol>
>      </li>
>      <li class="list-header">Wet:
>        <ol>
>            <li>1 egg</li>
>            <li>1/2c milk</li>
>            <li>1tsp vanilla extract</li>
>        </ol>
>      </li>
>     </ol>

A different use case in the same problem field: Often you have lists 
that are actually part of a paragraph, but cannot be correctly 
associated with the paragraph:

<p>Text before ...</p>
<p>There are lots of fruits available, e.g.:</p>
<ul>
   <li>Apples</li>
   <li>Pears</li>
</ul>
<p>More Text...</p>

More appropriate markup for this could be achieved with the LH suggestion:

<p>Text before ...</p>
<ul>
   <lh>There are lots of fruits available, e.g.:</lh>
   <li>Apples</li>
   <li>Pears</li>
</ul>
<p>More Text...</p>

Anyway I would consider it even more appropriate to allow the list 
inside a paragraph:

<p>Text before ...</p>
<p>There are lots of fruits available, e.g.:
   <ul>
     <li>Apples</li>
     <li>Pears</li>
   </ul>
</p>
<p>More Text...</p>

But I admit I have no idea what other problems this could cause.


From bhawkeslewis at googlemail.com  Thu Feb  5 01:08:14 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Thu, 05 Feb 2009 09:08:14 +0000
Subject: [whatwg] List Headers
In-Reply-To: <498AA0BB.9030501@gmx.ch>
References: <49896A54.2040607@sanchothefat.com>	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>	<498972DB.1060107@lachy.id.au>	<c9e12660902041239n395f3c18o1e76441049e7b03c@mail.gmail.com>	<498A02A7.9050904@googlemail.com>
	<498AA0BB.9030501@gmx.ch>
Message-ID: <498AAC7E.4080009@googlemail.com>

On 5/2/09 08:18, Markus Ernst wrote:
> A different use case in the same problem field: Often you have lists
> that are actually part of a paragraph, but cannot be correctly
> associated with the paragraph:
>
> <p>Text before ...</p>
> <p>There are lots of fruits available, e.g.:</p>
> <ul>
> <li>Apples</li>
> <li>Pears</li>
> </ul>
> <p>More Text...</p>
>
> More appropriate markup for this could be achieved with the LH suggestion:
>
> <p>Text before ...</p>
> <ul>
> <lh>There are lots of fruits available, e.g.:</lh>
> <li>Apples</li>
> <li>Pears</li>
> </ul>
> <p>More Text...</p>
>
> Anyway I would consider it even more appropriate to allow the list
> inside a paragraph:
> <p>Text before ...</p>
> <p>There are lots of fruits available, e.g.:
> <ul>
> <li>Apples</li>
> <li>Pears</li>
> </ul>
> </p>
> <p>More Text...</p>
>
> But I admit I have no idea what other problems this could cause.

I agree (?) that the use case you raise is not "list headers" but lists 
inside paragraphs, and I agree that nested block content can 
legitimately be placed inside a paragraph - it certainly is in print. 
Other examples of legitimately nested content would include quotations 
and perhaps tables.

But HTML5 cannot allow "ul" (or "blockquote" or "table") as children of 
"p" in the text/html serialization because legacy content relies on "p" 
end-tag insertion before those block element's start tags. In other 
words, web-corpus-compatible parsers need to parse the above as 
equivalent to:

<p>Text before ...</p>
<p>There are lots of fruits available, e.g.:</p>
<ul>
<li>Apples</li>
<li>Pears</li>
</ul>
<p></p>
<p>More Text...</p>

HTML5's definition of how to interpret non-"p" content as "paragraphs" 
excludes using any alternate wrapper (e.g. "div") to wrap the text and 
the "ul" as one semantic paragraph.

http://www.whatwg.org/specs/web-apps/current-work/#paragraphs

<div>Hamlet said:
<blockquote><p>To be or not to be, that is the question</p></blockquote>
? and lots of other things.</div>

is to be interpreted as three serial paragraphs not one paragraph with a 
paragraph in a nested quotation.

Using a "div" wrapper or adding a class ("continuation"?) to nested and 
continuing fragments will at least allow authors to emulate print 
conventions with CSS, however.

I believe nesting blocks inside "p" elements is currently allowed in the 
XML serialization, however, since HTML5 does not face the same 
web-corpus-parsing constraints there.

--
Benjamin Hawkes-Lewis


From mail at tobyinkster.co.uk  Thu Feb  5 14:23:42 2009
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Thu, 5 Feb 2009 22:23:42 +0000
Subject: [whatwg] List Headers
Message-ID: <185A3146-8241-44D9-A45F-D587F9DDB9C6@tobyinkster.co.uk>

Ian Hickson wrote:

> ...looks like it should work, but in practice the <lh> element for
> Vegetables would end up inside the Pear <li> element, and changing  
> that
> would likely be problematic.

... because of the vast number of existing pages that rely on <lh>  
elements being parsed inside <li> elements?

-- 
Toby A Inkster
<mailto:mail at tobyinkster.co.uk>
<http://tobyinkster.co.uk>





From ian at hixie.ch  Thu Feb  5 14:33:03 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 5 Feb 2009 22:33:03 +0000 (UTC)
Subject: [whatwg] List Headers
In-Reply-To: <185A3146-8241-44D9-A45F-D587F9DDB9C6@tobyinkster.co.uk>
References: <185A3146-8241-44D9-A45F-D587F9DDB9C6@tobyinkster.co.uk>
Message-ID: <Pine.LNX.4.62.0902052231210.952@hixie.dreamhostps.com>

On Thu, 5 Feb 2009, Toby A Inkster wrote:
> Ian Hickson wrote:
> 
> > ...looks like it should work, but in practice the <lh> element for 
> > Vegetables would end up inside the Pear <li> element, and changing 
> > that would likely be problematic.
> 
> ... because of the vast number of existing pages that rely on <lh> 
> elements being parsed inside <li> elements?

More because of the conflict between how pages would be parsed (and thus 
styled) in new browsers vs legacy browsers. For example, look at the 
problems that introducing <section> (or worse, <figure>) has caused. 
Changing the parser rules is a very expensive proposition.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From scampa.giovanni at gmail.com  Fri Feb  6 09:54:52 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Fri, 6 Feb 2009 18:54:52 +0100
Subject: [whatwg] [html5] Rendering of interactive content
Message-ID: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>

I'm proposing to replace the current rendering mechanism, based on
Behavioural Extension to CSS, that in turn is based on XBL2, with something
based on the CSS3 Basic User Interface (css3-ui), ie replacing the binding:
property with appropriate appearance: property directly on the element,
instead of relying on the binding itself.

This in particular applies to the button, input, select and textarea.
Something like this could be included:

button,input[type=submit],input[type=button],input[type=reset] {
appearance:push-button;
}
input[type=submit],input[type=button],input[type=reset] {
content:attr(value,string,contents);
}
input {
appearance:field;
border-width: calc(attr(size,px,0) / 2); /* presentational hint */
}
input[type=password] {
appearance:password;
}
input[type=url]::outside::after {
appearance:push-button;
content:icon;
icon: url(<icon uri>);
} /* the current appearance in Opera */
input[type=range] {
appearance:range; /* Webkit uses a proprietary -webkit-slider-horizontal for
this */
}
input[type=checkbox] {
appearance:checkbox;
}
input[type=radio] {
appearance:radiobutton;
}
input[type=file]::outside::after {
appearance:push-button;
content: "Browse...";
}
select[size] {
appearance:list-menu;
}
select,select[size=1] {
appearance:pop-up-menu;
}

The advantage of appearance vs binding is that:
1) you don't need an additional pass before applying the correct
platform-specific widget style
2) you depend on css3-ui, in CR stage, instead of becss, a very early WD
3) you don't block the binding property: I don't expect that applying an XBL
binding on an element causes it to appear like a span (because it gets
almost no default CSS)
4) you keep the appearance property working: current UA (Firefox and Safari
at least) already implement appearance, and correctly set it on the input
element. This could no longer be possible using XBL, because of the CSS
inheritance model inside XBL (if you apply to appearance to some part of the
shadow tree, it is not visible on the bound element)
5) becss requires "one or more binding languages": it is not necessarily
XBL2, but currently XBL2 is the only one available: are you constraining the
implementation of HTML5 on that of XBL2?

~ o ~

A part from that, I would like to propose the following CSS for some missing
parts:

marquee[behaviour=slide] {
marquee-style:slide;
}
marquee[behaviour=scroll] {
marquee-style:scroll;
}
marquee[behaviour=alternate] {
marquee-style:slide;
}
marquee[direction=left] {
marquee-direction:forward;
overflow-style:marquee-line;
}
marquee[direction=right] {
marquee-direction:backward;
overflow-style:marquee-line;
}
marquee[direction=up] {
marquee-direction:backward;
overflow-style:marquee-block;
}
marquee[direction=down] {
marquee-direction:forward;
overflow-style:marquee-block;
}
marquee[loop] {
marquee-play-count: attr(loop,integer,initial);
}

(This obviously means that we need a definition of marquee accepting
attributes behaviour = (slide | scroll | alternate), direction = (left |
right | up | down), loop = <integer>. Info found from MSDN).

progress {
display:block;
content:none;
background-color:green;
width: calc(1% * attr(value,number,0) / attr(max,number,1) );
}
progress::outside {
display:block;
text-align:center;
width:auto;
content:contents;
}
progress:empty::outside {
content:calc(attr(value,number,0) / attr(max,number,1) * 100) "%";
}

The same could apply for meter as well, except for the handling of optimal
and suboptimal parts.

menu[type=toolbar] {
appearance:menu-bar; /* are menu bars visually different from tool bars? */
}
menu[type=context]:active {
appearance:menu;
display:block; /* may be actually implied by appearance:menu */
}
menu[type=toolbar] > menu::outside::before, menu[type=toolbar] >
select::outside::before, menu[type=toolbar] > menu::outside::after,
menu[type=toolbar] > select::outside::after, menu[type=toolbar] > hr,
menu[type=toolbar] > option[value=]:disabled, menu[type=context] >
menu::outside::before, menu[type=context] > select::outside::before,
menu[type=toolbar] > menu::outside::after, menu[type=toolbar] >
select::outside::after, menu[type=context] > hr, menu[type=context] >
option[value=]:disabled { /* separators */
display:block;
content:"";
border: 1px solid ThreeDFace;
width:0px;
}
menu[type=toolbar] > menu[label], menu[type=toolbar] > optgroup[label],
menu[type=context] > menu[label], menu[type=context] > optgroup[label] {
appearance:pull-down-menu; /* actually, where are we supposed to specify the
label? */
}
menu[type=toolbar] a, menu[type=toolbar] button, menu[type=toolbar]
input[type=submit], menu[type=toolbar] input[type=reset], menu[type=toolbar]
input[type=button], menu[type=toolbar] input[type=checkbox],
menu[type=toolbar] input[type=radio], menu[type=toolbar] select option,
menu[type=toolbar] command, menu[type=toolbar] bb, menu[type=context] a,
menu[type=context] button, menu[type=context] input[type=submit],
menu[type=context] input[type=reset], menu[type=context] input[type=button],
menu[type=context] input[type=checkbox], menu[type=context]
input[type=radio], menu[type=toolbar] select option, menu[type=context]
command, menu[type=context] bb { /* commands */
appearance:menu-item;
}

I hope that this will help a bit the editor.

Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090206/800a86bb/attachment.htm>

From ian at hixie.ch  Fri Feb  6 10:46:49 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 6 Feb 2009 18:46:49 +0000 (UTC)
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>

On Fri, 6 Feb 2009, Giovanni Campagna wrote:
>
> I'm proposing to replace the current rendering mechanism, based on 
> Behavioural Extension to CSS, that in turn is based on XBL2, with 
> something based on the CSS3 Basic User Interface (css3-ui), ie replacing 
> the binding: property with appropriate appearance: property directly on 
> the element, instead of relying on the binding itself.

The two properties are orthogonal -- 'binding' sets the behavior, 
'appearance' sets the look-and-feel.


> The advantage of appearance vs binding is that:
> 1) you don't need an additional pass before applying the correct
> platform-specific widget style

With UA-native bindings, you wouldn't need an additional pass either.


> 2) you depend on css3-ui, in CR stage, instead of becss, a very early WD

BECSS is actually probably more stable than CSS3 UI at this point.


> 3) you don't block the binding property: I don't expect that applying an XBL
> binding on an element causes it to appear like a span (because it gets
> almost no default CSS)

This is actually intentional. Experience with elements like <fieldset> 
that have styles that aren't expressed in CSS is that you end up not being 
able to restyle them properly if you desire. With 'binding' we'd be able 
to knock out the whole default rendering (including weird things with the 
children) in one go.


> 4) you keep the appearance property working: current UA (Firefox and Safari
> at least) already implement appearance, and correctly set it on the input
> element. This could no longer be possible using XBL, because of the CSS
> inheritance model inside XBL (if you apply to appearance to some part of the
> shadow tree, it is not visible on the bound element)

I don't understand what you mean here.


> 5) becss requires "one or more binding languages": it is not necessarily 
> XBL2, but currently XBL2 is the only one available: are you constraining 
> the implementation of HTML5 on that of XBL2?

The rendering section has no actual requirements in it, so nothing is 
constrained. Furthermore, nothing requires the binding language used by 
the UA to actually be a real language, so long as it is triggered by the 
'binding' property.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From scampa.giovanni at gmail.com  Sat Feb  7 06:22:23 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Sat, 7 Feb 2009 15:22:23 +0100
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
Message-ID: <65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>

2009/2/6 Ian Hickson <ian at hixie.ch>

> On Fri, 6 Feb 2009, Giovanni Campagna wrote:
> >
> > I'm proposing to replace the current rendering mechanism, based on
> > Behavioural Extension to CSS, that in turn is based on XBL2, with
> > something based on the CSS3 Basic User Interface (css3-ui), ie replacing
> > the binding: property with appropriate appearance: property directly on
> > the element, instead of relying on the binding itself.
>
> The two properties are orthogonal -- 'binding' sets the behavior,
> 'appearance' sets the look-and-feel.
>
> I thought about it later, and I realized that you cannot style complex
widgets without XBL (or something like that) because pseudo-elements are not
reached by events. If they ever would, we would have horrible situations we
have now.
So for complex widgets (Number, File, Slider) it may be impossible to avoid
a binding property, but anywhere it is possible you should try to use the
available (appearance, content, icon, etc.). Even when using those, the
author is able to shut them down, and knows perfectly which of them apply
(they're defined normatively in HTML5 and they're exposed by browser tools
for web dev). This allows for them to be selectively disabled, eg. to show
BB without a button but with the native icon.
What is more important, is that appearance normatively defines what
properties from outside the appearance definition are allowed to interfere
with the native look of the widget, binding does not. If author style sheets
are not imported in XBL (apply-author-sheets="false"), they don't apply at
all.

> The advantage of appearance vs binding is that:
> > 1) you don't need an additional pass before applying the correct
> > platform-specific widget style
>
> With UA-native bindings, you wouldn't need an additional pass either.
>
The current spec says "User agents are encouraged to make their bindings set
the 'appearance' CSS property appropriately to achieve platform-native
appearances for widgets": this means that the binding should set appearance,
and then appearance should make the widget look like a normal button.

>
> > 2) you depend on css3-ui, in CR stage, instead of becss, a very early WD
>
> BECSS is actually probably more stable than CSS3 UI at this point.
>
Why do you say so? Will CSS3 UI go back to Last Call or BECSS process to
Last Call in the near future? I'm not sure. In the mean time, CSS3 UI is
final, and waiting only for implementation.

>
> > 3) you don't block the binding property: I don't expect that applying an
> XBL
> > binding on an element causes it to appear like a span (because it gets
> > almost no default CSS)
>
> This is actually intentional. Experience with elements like <fieldset>
> that have styles that aren't expressed in CSS is that you end up not being
> able to restyle them properly if you desire. With 'binding' we'd be able
> to knock out the whole default rendering (including weird things with the
> children) in one go.
>
The fact is that binding it the best way to apply a set of event handlers to
an element. Having to tweak the computed style of a fieldset in order to
find what properties are actually set and reproduce them in the binding,
just to put a set of onchange handlers to lots of fieldset, does not look
optimal.


>
> > 4) you keep the appearance property working: current UA (Firefox and
> Safari
> > at least) already implement appearance, and correctly set it on the input
> > element. This could no longer be possible using XBL, because of the CSS
> > inheritance model inside XBL (if you apply to appearance to some part of
> the
> > shadow tree, it is not visible on the bound element)
>
> I don't understand what you mean here.
>
I mean that Firefox and Safari set the appearance property on the widget
element, and it is visible from outside, and dynamically changeable at run
time. The binding property instead contains an opaque and UA specific value,
that is not intended to be changed from JS (to switch back and forth between
widget types)

>
> > 5) becss requires "one or more binding languages": it is not necessarily
> > XBL2, but currently XBL2 is the only one available: are you constraining
> > the implementation of HTML5 on that of XBL2?
>
> The rendering section has no actual requirements in it, so nothing is
> constrained. Furthermore, nothing requires the binding language used by
> the UA to actually be a real language, so long as it is triggered by the
> 'binding' property.
>

"A number of elements have their rendering defined in terms of the 'binding'
property" (HTML5, with normative reference to BECSS)
No BECSS --> no rendering --> no interoperability
"A user agent cannot comply to this specification without also supporting
one or more binding languages such as XBL" (BECSS, with informative
reference to XBL2)
Do you know any other binding languages outside XBL or HTC (that uses
behaviour instead of binding)?
"*Computed Value:* specified value, with URIs resolved to absolute URIs "
"When a specified URI cannot be used, e.g. due to network errors or because
the specified binding is in an unsupported language, that specified URI must
be ignored, without affecting the other URIs specified."
This means that the binding property must be an absolute <uri>, indicating a
network retrievable resource (no about: or urn: URI) in a supported language

>
> Cheers,
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Giovanni

PS: did you find useful the remaining material, eg. menu, meter, marquee?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090207/f66f75b1/attachment.htm>

From bhawkeslewis at googlemail.com  Sat Feb  7 10:44:23 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Sat, 07 Feb 2009 18:44:23 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
Message-ID: <498DD687.7060303@googlemail.com>

On 7/2/09 14:22, Giovanni Campagna wrote:
>      > 5) becss requires "one or more binding languages": it is not
>     necessarily
>      > XBL2, but currently XBL2 is the only one available: are you
>     constraining
>      > the implementation of HTML5 on that of XBL2?
>
>     The rendering section has no actual requirements in it, so nothing is
>     constrained. Furthermore, nothing requires the binding language used by
>     the UA to actually be a real language, so long as it is triggered by the
>     'binding' property.
>
>
> "A number of elements have their rendering defined in terms of the
> 'binding' property" (HTML5, with normative reference to BECSS)
> No BECSS --> no rendering --> no interoperability

The introduction to the rendering section says:

'User agents are not required present HTML documents in any particular 
way. However, this section provides a set of suggestions for rendering 
HTML documents that, if followed, are likely to lead to a user 
experience that closely resembles the experience intended by the 
documents' authors. So as to avoid confusion regarding the normativity 
of this section, RFC2119 terms have not been used. Instead, the term 
"expected" is used to indicate behavior that will lead to this experience.'

http://www.whatwg.org/specs/web-apps/current-work/#rendering

So the rendering section imposes *no* requirements on HTML5 conforming 
user agents, therefore the spec is not "constraining the implementation 
of HTML5 on that of XBL2".

Furthermore, user agents are free to use any method they like to mimic 
the suggested rendering, including CSS3 UI where applicable. They don't 
have to use BE CSS at all.

If this is not obvious from the text, perhaps you would like to suggest 
a change to the text that would make it clearer?

--
Benjamin Hawkes-Lewis


From scampa.giovanni at gmail.com  Sat Feb  7 10:51:33 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Sat, 7 Feb 2009 19:51:33 +0100
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <498DD687.7060303@googlemail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
	<498DD687.7060303@googlemail.com>
Message-ID: <65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>

2009/2/7 Benjamin Hawkes-Lewis <bhawkeslewis at googlemail.com>

> On 7/2/09 14:22, Giovanni Campagna wrote:
>
>>     > 5) becss requires "one or more binding languages": it is not
>>    necessarily
>>     > XBL2, but currently XBL2 is the only one available: are you
>>    constraining
>>     > the implementation of HTML5 on that of XBL2?
>>
>>    The rendering section has no actual requirements in it, so nothing is
>>    constrained. Furthermore, nothing requires the binding language used by
>>    the UA to actually be a real language, so long as it is triggered by
>> the
>>    'binding' property.
>>
>>
>> "A number of elements have their rendering defined in terms of the
>> 'binding' property" (HTML5, with normative reference to BECSS)
>> No BECSS --> no rendering --> no interoperability
>>
>
> The introduction to the rendering section says:
>
> 'User agents are not required present HTML documents in any particular way.
> However, this section provides a set of suggestions for rendering HTML
> documents that, if followed, are likely to lead to a user experience that
> closely resembles the experience intended by the documents' authors. So as
> to avoid confusion regarding the normativity of this section, RFC2119 terms
> have not been used. Instead, the term "expected" is used to indicate
> behavior that will lead to this experience.'
>
> http://www.whatwg.org/specs/web-apps/current-work/#rendering
>
> So the rendering section imposes *no* requirements on HTML5 conforming user
> agents, therefore the spec is not "constraining the implementation of HTML5
> on that of XBL2".


Yes, but UA that don't follow that set of CSS rules are not interoperable
with UA that follow, ie scripts must detect what properties are ignored or
defaulted.

>
>
> Furthermore, user agents are free to use any method they like to mimic the
> suggested rendering, including CSS3 UI where applicable. They don't have to
> use BE CSS at all.

They're "expected" to use CSS, and I expect that, according to html5,
"button { binding: initial; }" makes it like a <span>.


>
> If this is not obvious from the text, perhaps you would like to suggest a
> change to the text that would make it clearer?

I don't agree with rendering being "optional". If interoperability is so
important (and it is), rendering should be normative. Obviously I'm not
asking to depend on CSS, I'm asking that "UA should act if the following CSS
was specified" (even if it doesn't support CSS)

>
> --
> Benjamin Hawkes-Lewis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090207/efbcf8e5/attachment.htm>

From bhawkeslewis at googlemail.com  Sat Feb  7 11:24:53 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Sat, 07 Feb 2009 19:24:53 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>	
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>	
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>	
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
Message-ID: <498DE005.2070502@googlemail.com>

On 7/2/09 18:51, Giovanni Campagna wrote:
>     So the rendering section imposes *no* requirements on HTML5
>     conforming user agents, therefore the spec is not "constraining the
>     implementation of HTML5 on that of XBL2".
>
>
> Yes, but UA that don't follow that set of CSS rules are not
> interoperable with UA that follow, ie scripts must detect what
> properties are ignored or defaulted.

HTML5 conforming UAs do not have to implement CSS or CSSOM.

CSSOM-implementing UAs do not have to do express all styling with CSS 
properties.

When they do, you can query for those properties via the CSSOM.

>     Furthermore, user agents are free to use any method they like to
>     mimic the suggested rendering, including CSS3 UI where applicable.
>     They don't have to use BE CSS at all.
>
> They're "expected" to use CSS, and I expect that, according to html5,
> "button { binding: initial; }" makes it like a <span>.

Is text I quoted not clear that the word "expected" is chosen precisely 
to make it clear that these are _not_ normative requirements? If so, 
could you suggest modifications to the text to make it even clearer?

>     If this is not obvious from the text, perhaps you would like to
>     suggest a change to the text that would make it clearer?
>
> I don't agree with rendering being "optional". If interoperability is so
> important (and it is), rendering should be normative.

How does that follow?

And what do you mean by "rendering should be normative"?

Are you suggesting, for example, that HTML5 should mandate unvisited 
links be blue and underlined in the screen medium unless set otherwise 
by a publisher stylesheet? That would prevent UAs providing a default 
presentation of semantic HTML that suits the end-user!

Note that would prevent UAs complying with W3C's user-agent 
accessibility guidelines:

http://www.w3.org/TR/WAI-USERAGENT/guidelines.html#gl-user-control-styles

--
Benjamin Hawkes-Lewis



From scampa.giovanni at gmail.com  Sat Feb  7 12:07:53 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Sat, 7 Feb 2009 21:07:53 +0100
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <498DE005.2070502@googlemail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
	<498DE005.2070502@googlemail.com>
Message-ID: <65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>

2009/2/7 Benjamin Hawkes-Lewis <bhawkeslewis at googlemail.com>

> On 7/2/09 18:51, Giovanni Campagna wrote:
>
>>    So the rendering section imposes *no* requirements on HTML5
>>    conforming user agents, therefore the spec is not "constraining the
>>    implementation of HTML5 on that of XBL2".
>>
>>
>> Yes, but UA that don't follow that set of CSS rules are not
>> interoperable with UA that follow, ie scripts must detect what
>> properties are ignored or defaulted.
>>
>
> HTML5 conforming UAs do not have to implement CSS or CSSOM.
>
> CSSOM-implementing UAs do not have to do express all styling with CSS
> properties.
>
> When they do, you can query for those properties via the CSSOM.
>

Yes, but what properties should I query for? Binding, behaviour, appearance,
border, color, font, all in once? And what should their values be?

>
>     Furthermore, user agents are free to use any method they like to
>>    mimic the suggested rendering, including CSS3 UI where applicable.
>>    They don't have to use BE CSS at all.
>>
>> They're "expected" to use CSS, and I expect that, according to html5,
>> "button { binding: initial; }" makes it like a <span>.
>>
>
> Is text I quoted not clear that the word "expected" is chosen precisely to
> make it clear that these are _not_ normative requirements? If so, could you
> suggest modifications to the text to make it even clearer?
>
>     If this is not obvious from the text, perhaps you would like to
>>    suggest a change to the text that would make it clearer?
>>
>> I don't agree with rendering being "optional". If interoperability is so
>> important (and it is), rendering should be normative.
>>
>
> How does that follow?


If <input type="submit"> in some UA is rendered with all properties set to
initial, not only it does not express the semantic of a button, but it may
be difficult for a user to actually recognize it as a button and eventually
click it. In that case I, as the author, may need to manually set {
appearance:push-button; content:attr(value,string,"Send"); } in order to
have my form submitted.
Try this example (in Firefox or Safari):
data:text/html,<style>label { position:fixed; top:-1em; border:1px solid
black; } label input { -moz-appearance:none; -webkit-appearance:none;
border:none; width:auto; } input[type=submit] { -moz-appearance:none;
-webkit-appearance:none; background-color:transparent; border:none;
}</style><form action="http://www.google.com/search"
method="get"><label>Search: <input type="text" value=""
name="q"></label><input type=submit value="Go">

Imagine that was the UA default stylesheet instead of an author stylesheet
and you may see what interoperability means with web application look and
feel.

>
>
> And what do you mean by "rendering should be normative"?
>
> Are you suggesting, for example, that HTML5 should mandate unvisited links
> be blue and underlined in the screen medium unless set otherwise by a
> publisher stylesheet? That would prevent UAs providing a default
> presentation of semantic HTML that suits the end-user!
>
> Note that would prevent UAs complying with W3C's user-agent accessibility
> guidelines:
>
> http://www.w3.org/TR/WAI-USERAGENT/guidelines.html#gl-user-control-styles


HTML5 should not mandate the UA present <a>s in blue, but it should mandate
the UA present <a>s like links (appearance:hyperlink). The color of course
is a matter of visual themes and platform.
An other example: HTML5 should mandate <button> displayed with
appearance:push-button; even if the UA doesn't support CSS.
Also compare it to the normative style sheet for XHTML2 [1]: it does not
require CSS, but it does require that some look and feel (very basic
actually) is enforced to express the semantics of elements.
Obviously this does not relate in any way with user preferences, here we
talk about UA defaults.

--
> Benjamin Hawkes-Lewis
>

Giovanni

[1] http://www.w3.org/TR/xhtml2/xhtml2-style.html#a_stylesheet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090207/6a14d23c/attachment.htm>

From bhawkeslewis at googlemail.com  Sat Feb  7 16:21:47 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Sun, 08 Feb 2009 00:21:47 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>	
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>	
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>	
	<498DD687.7060303@googlemail.com>	
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>	
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
Message-ID: <498E259B.3010300@googlemail.com>

On 7/2/09 20:07, Giovanni Campagna wrote:
> Yes, but what properties should I query for?

In order to find out what, precisely?

> Binding, behaviour, appearance, border, color, font, all in once? And
> what should their values be?

Their values depend on user agent defaults (which may be anything), user 
preferences (which may be anything), user stylesheets (which may be 
anything), and publisher styles (which may be anything), as per the CSS 
cascade:

http://www.w3.org/TR/CSS21/cascade.html#cascade

In other words, the values cannot be known for sure until you query them.

Even if you mandated precise user agent defaults, the values still could 
not be known for sure until you queried them, because of user 
preferences, user stylesheets, and publisher styles.

> If <input type="submit"> in some UA is rendered with all properties set
> to initial, not only it does not express the semantic of a button, but
> it may be difficult for a user to actually recognize it as a button and
> eventually click it.
> In that case I, as the author, may need to manually
> set { appearance:push-button; content:attr(value,string,"Send"); } in
> order to have my form submitted.
> Try this example (in Firefox or Safari):
> data:text/html,<style>label { position:fixed; top:-1em; border:1px solid
> black; } label input { -moz-appearance:none; -webkit-appearance:none;
> border:none; width:auto; } input[type=submit] { -moz-appearance:none;
> -webkit-appearance:none; background-color:transparent; border:none;
> }</style><form action="http://www.google.com/search"
> method="get"><label>Search: <input type="text" value=""
> name="q"></label><input type=submit value="Go">
>
> Imagine that was the UA default stylesheet instead of an author
> stylesheet and you may see what interoperability means with web
> application look and feel.

There's a recursion problem there.

User agents may derive the effects of "appearance" from user-agent 
default stylesheets:

http://www.w3.org/TR/css3-ui/#appearance

If the user agent default stylesheet does not style push buttons 
differently from other content, and the user agent derives the effects 
of appearance from that stylesheet, then checking or setting the value 
of appearance would not guarantee that your submit button would appear 
button-like.

> HTML5 should not mandate the UA present <a>s in blue, but it should
> mandate the UA present <a>s like links (appearance:hyperlink).

How would you test whether a UA complied with that requirement or not? 
Purely by testing the value of the appearance property applied to the 
element with a default configuration?

> Obviously this does not relate in any way with user preferences, here we
> talk about UA defaults.

What if a developer wants to create a UA reflecting a target market's 
differing preferences for presentation, rather than require the users to 
configure it first?

Are you proposing such a UA should be non-conforming?

--
Benjamin Hawkes-Lewis


From scampa.giovanni at gmail.com  Sun Feb  8 05:18:27 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Sun, 8 Feb 2009 14:18:27 +0100
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <498E259B.3010300@googlemail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<498E259B.3010300@googlemail.com>
Message-ID: <65307430902080518x4c6ad12do3570775d02d884c1@mail.gmail.com>

2009/2/8 Benjamin Hawkes-Lewis <bhawkeslewis at googlemail.com>

> On 7/2/09 20:07, Giovanni Campagna wrote:
>
>> Yes, but what properties should I query for?
>>
>
> In order to find out what, precisely?
>
What to reset, for example (see the first Ian email on this topic)


>
>  Binding, behaviour, appearance, border, color, font, all in once? And
>> what should their values be?
>>
>
> Their values depend on user agent defaults (which may be anything), user
> preferences (which may be anything), user stylesheets (which may be
> anything), and publisher styles (which may be anything), as per the CSS
> cascade:

I am the author, so at least those values are known. For what concern user
stylesheets, I should try to override them, it is the user that wants them.
So the only properties I may find useful to know the values are UA default,
that should be consistent across different platform and browser.


>
> http://www.w3.org/TR/CSS21/cascade.html#cascade
>
> In other words, the values cannot be known for sure until you query them.
>
> Even if you mandated precise user agent defaults, the values still could
> not be known for sure until you queried them, because of user preferences,
> user stylesheets, and publisher styles.
>

If you mandate strict UA default, and the publisher (I repeat, I am the
author, I know what I write) overrides them, he may be sure that: either it
will look as no default style applied at all, or any additional property
that applies has been set by the user (so it is not my problem, he wanted
all the <a>s to be purple on yellow background, even if it looks horrible to
me)

>
>  If <input type="submit"> in some UA is rendered with all properties set
>> to initial, not only it does not express the semantic of a button, but
>> it may be difficult for a user to actually recognize it as a button and
>> eventually click it.
>> In that case I, as the author, may need to manually
>> set { appearance:push-button; content:attr(value,string,"Send"); } in
>> order to have my form submitted.
>> Try this example (in Firefox or Safari):
>> data:text/html,<style>label { position:fixed; top:-1em; border:1px solid
>> black; } label input { -moz-appearance:none; -webkit-appearance:none;
>> border:none; width:auto; } input[type=submit] { -moz-appearance:none;
>> -webkit-appearance:none; background-color:transparent; border:none;
>> }</style><form action="http://www.google.com/search"
>> method="get"><label>Search: <input type="text" value=""
>> name="q"></label><input type=submit value="Go">
>>
>> Imagine that was the UA default stylesheet instead of an author
>> stylesheet and you may see what interoperability means with web
>> application look and feel.
>>
>
> There's a recursion problem there.
>
> User agents may derive the effects of "appearance" from user-agent default
> stylesheets:
>
> http://www.w3.org/TR/css3-ui/#appearance
>

UA must derive the appearance effects from the user agent skin, widgets
theme or native platform widgets (ie the common controls on win or the Gtk /
Qt themes in Linux). Those settings are not part of the UA default style
sheet, are not necessarily expressed in CSS, and do not take part in the
cascade.

>
> If the user agent default stylesheet does not style push buttons
> differently from other content, and the user agent derives the effects of
> appearance from that stylesheet, then checking or setting the value of
> appearance would not guarantee that your submit button would appear
> button-like.
>
>  HTML5 should not mandate the UA present <a>s in blue, but it should
>> mandate the UA present <a>s like links (appearance:hyperlink).
>>
>
> How would you test whether a UA complied with that requirement or not?
> Purely by testing the value of the appearance property applied to the
> element with a default configuration?

1) you test the conformance to HTML5 by testing the value of appearance and
the semantics of the element (it must be an hyper-link, if you want
normative rendering or not)
2) you test the conformance to CSS3 UI by testing the look and feel of the
elements, and comparing it to the standard look and feel for that platform,
skin, them, etc.

>
>
>  Obviously this does not relate in any way with user preferences, here we
>> talk about UA defaults.
>>
>
> What if a developer wants to create a UA reflecting a target market's
> differing preferences for presentation, rather than require the users to
> configure it first?
>
> Are you proposing such a UA should be non-conforming?


Could you propose an example of this UA, that still preserves the semantics
of the elements, as required by HTML5?

>
>
> --
> Benjamin Hawkes-Lewis
>

Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090208/3a0d7eae/attachment.htm>

From bzbarsky at MIT.EDU  Sun Feb  8 05:37:32 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Sun, 08 Feb 2009 08:37:32 -0500
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902080518x4c6ad12do3570775d02d884c1@mail.gmail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>	<498DD687.7060303@googlemail.com>	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>	<498DE005.2070502@googlemail.com>	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>	<498E259B.3010300@googlemail.com>
	<65307430902080518x4c6ad12do3570775d02d884c1@mail.gmail.com>
Message-ID: <498EE01C.7000006@mit.edu>

Giovanni Campagna wrote:
> Could you propose an example of this UA, that still preserves the 
> semantics of the elements, as required by HTML5?

A UA that differentiates, in its default styling, between same-site 
links and links to a different site.

-Boris



From Smylers at stripey.com  Sun Feb  8 05:40:44 2009
From: Smylers at stripey.com (Smylers)
Date: Sun, 8 Feb 2009 13:40:44 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
Message-ID: <20090208134044.GA3459@stripey.com>

Giovanni Campagna writes:

> If <input type="submit"> in some UA is rendered with all properties
> set to initial, not only it does not express the semantic of a button,
> but it may be difficult for a user to actually recognize it as a
> button and eventually click it. In that case I, as the author, may
> need to manually set { appearance:push-button;
> content:attr(value,string,"Send"); } in order to have my form
> submitted.  Try this example (in Firefox or Safari):
> data:text/html,<style>label { position:fixed; top:-1em; border:1px
> solid black; } label input { -moz-appearance:none;
> -webkit-appearance:none; border:none; width:auto; } input[type=submit]
> { -moz-appearance:none; -webkit-appearance:none;
> background-color:transparent; border:none; }</style><form
> action="http://www.google.com/search" method="get"><label>Search:
> <input type="text" value="" name="q"></label><input type=submit
> value="Go">
> 
> Imagine that was the UA default stylesheet instead of an author
> stylesheet and you may see what interoperability means with web
> application look and feel.

Indeed it would be a problem if a major web browser shipped with such a
default style-sheet.  But ... I'm really having trouble imagining any of
them doing so.  It isn't in mainstream browsers' interests to produce
products which purposefully confuse their users.

Surely a browser which disguises buttons as plain text is going to lose
market share of its own accord, regardless of what HTML 5 says?

Or, to look at it from the opposite direction, supposing a browser
producer really wanted to make buttons look like plain text, would
whether HTML 5 condemns this practice really affect what they do?  Would
not being able to market their browser as HTML-5-compliant be enough
that they'd begrudgingly forget their desire?  Would users dissatisfied
with the behaviour only complain because it breaches HTML 5, rather than
because, say, it's really stupid?

I can't see how a requirement such as you propose would make any
practical difference on avoiding the outcomes you wish to avoid.  But it
might unnecessarily curtail innovation in directions that we haven't yet
envisaged -- perhaps somebody developing a specialist user-agent for
mobile devices (or digital TV, or for print-based output, or
large-screen non-interactive displays, or ...) comes up with a different
way of displaying certainly elements which she considers is superior for
her particular target audience; why should the spec attempt to dissuade
her from doing so?

Smylers


From Smylers at stripey.com  Sun Feb  8 05:40:44 2009
From: Smylers at stripey.com (Smylers)
Date: Sun, 8 Feb 2009 13:40:44 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
Message-ID: <20090208134044.GA3459@stripey.com>

Giovanni Campagna writes:

> If <input type="submit"> in some UA is rendered with all properties
> set to initial, not only it does not express the semantic of a button,
> but it may be difficult for a user to actually recognize it as a
> button and eventually click it. In that case I, as the author, may
> need to manually set { appearance:push-button;
> content:attr(value,string,"Send"); } in order to have my form
> submitted.  Try this example (in Firefox or Safari):
> data:text/html,<style>label { position:fixed; top:-1em; border:1px
> solid black; } label input { -moz-appearance:none;
> -webkit-appearance:none; border:none; width:auto; } input[type=submit]
> { -moz-appearance:none; -webkit-appearance:none;
> background-color:transparent; border:none; }</style><form
> action="http://www.google.com/search" method="get"><label>Search:
> <input type="text" value="" name="q"></label><input type=submit
> value="Go">
> 
> Imagine that was the UA default stylesheet instead of an author
> stylesheet and you may see what interoperability means with web
> application look and feel.

Indeed it would be a problem if a major web browser shipped with such a
default style-sheet.  But ... I'm really having trouble imagining any of
them doing so.  It isn't in mainstream browsers' interests to produce
products which purposefully confuse their users.

Surely a browser which disguises buttons as plain text is going to lose
market share of its own accord, regardless of what HTML 5 says?

Or, to look at it from the opposite direction, supposing a browser
producer really wanted to make buttons look like plain text, would
whether HTML 5 condemns this practice really affect what they do?  Would
not being able to market their browser as HTML-5-compliant be enough
that they'd begrudgingly forget their desire?  Would users dissatisfied
with the behaviour only complain because it breaches HTML 5, rather than
because, say, it's really stupid?

I can't see how a requirement such as you propose would make any
practical difference on avoiding the outcomes you wish to avoid.  But it
might unnecessarily curtail innovation in directions that we haven't yet
envisaged -- perhaps somebody developing a specialist user-agent for
mobile devices (or digital TV, or for print-based output, or
large-screen non-interactive displays, or ...) comes up with a different
way of displaying certainly elements which she considers is superior for
her particular target audience; why should the spec attempt to dissuade
her from doing so?

Smylers


From scampa.giovanni at gmail.com  Sun Feb  8 06:38:04 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Sun, 8 Feb 2009 15:38:04 +0100
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <20090208134044.GA3459@stripey.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<20090208134044.GA3459@stripey.com>
Message-ID: <65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>

2009/2/8 Smylers <Smylers at stripey.com>

> Giovanni Campagna writes:
>
> > If <input type="submit"> in some UA is rendered with all properties
> > set to initial, not only it does not express the semantic of a button,
> > but it may be difficult for a user to actually recognize it as a
> > button and eventually click it. In that case I, as the author, may
> > need to manually set { appearance:push-button;
> > content:attr(value,string,"Send"); } in order to have my form
> > submitted.  Try this example (in Firefox or Safari):
> > data:text/html,<style>label { position:fixed; top:-1em; border:1px
> > solid black; } label input { -moz-appearance:none;
> > -webkit-appearance:none; border:none; width:auto; } input[type=submit]
> > { -moz-appearance:none; -webkit-appearance:none;
> > background-color:transparent; border:none; }</style><form
> > action="http://www.google.com/search" method="get"><label>Search:
> > <input type="text" value="" name="q"></label><input type=submit
> > value="Go">
> >
> > Imagine that was the UA default stylesheet instead of an author
> > stylesheet and you may see what interoperability means with web
> > application look and feel.
>
> Indeed it would be a problem if a major web browser shipped with such a
> default style-sheet. But ... I'm really having trouble imagining any of
> them doing so.  It isn't in mainstream browsers' interests to produce
> products which purposefully confuse their users.
>
> Surely a browser which disguises buttons as plain text is going to lose
> market share of its own accord, regardless of what HTML 5 says?


> Or, to look at it from the opposite direction, supposing a browser
> producer really wanted to make buttons look like plain text, would
> whether HTML 5 condemns this practice really affect what they do?  Would
> not being able to market their browser as HTML-5-compliant be enough
> that they'd begrudgingly forget their desire?  Would users dissatisfied
> with the behaviour only complain because it breaches HTML 5, rather than
> because, say, it's really stupid?
>
> I can't see how a requirement such as you propose would make any
> practical difference on avoiding the outcomes you wish to avoid.  But it
> might unnecessarily curtail innovation in directions that we haven't yet
> envisaged -- perhaps somebody developing a specialist user-agent for
> mobile devices (or digital TV, or for print-based output, or
> large-screen non-interactive displays, or ...) comes up with a different
> way of displaying certainly elements which she considers is superior for
> her particular target audience; why should the spec attempt to dissuade
> her from doing so?
>
> Smylers
>

I agree with you that we must not constrain the innovation, but in that
case, what is the whole purpose of the Rendering section?
I think that section is for
- implementors of new UAs, that don't need to reverse engineer the
competitor products in order to find the defaults
- authors, that in this way know what to expect from the various UA with
less testing, that sometimes is also impossible, eg. you cannot test the
rendering of a mobile phone if you don't have a mobile phone
Having somewhere written that hyperlinks should be blue, allows you to style
the background-color to anything but blue.
If the UA suddenly displays hyperlinks in green and I decided that my
background is green, the user will complain with me, not with the UA (and
will probably switch to a different website)
Having somewhere said that <table> should be rendered as CSS tables, allows
you to put a border-collapse for example. If <table> suddenly starts to be
displayed as an hierarchical tree, my site may be broken at once.

The solutions are two:
1) either provide a default style sheets only for author and say: "you want
the usual rendering everywhere? import this". This means that the whole
Rendering sections should be moved to an Appendix and a separate
downloadable CSS file should be provided. In addition the "presentational
hints" become useless, since many of them cannot be expressed in terms of
CSS, and actually, all UA default style sheets are less important, because
most of time they will be overriden by author style sheets. Last, but not
least, you have to face an increased traffic to load an heavy CSS file just
for two or three display.
2) mandate a set of CSS properties and value.

Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090208/16f2e636/attachment.htm>

From Smylers at stripey.com  Sun Feb  8 08:45:47 2009
From: Smylers at stripey.com (Smylers)
Date: Sun, 8 Feb 2009 16:45:47 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
Message-ID: <20090208164547.GB3459@stripey.com>

Giovanni Campagna writes:

> 2009/2/8 Smylers <Smylers at stripey.com>
> 
> > Giovanni Campagna writes:
> >
> > > data:text/html,<style>label { position:fixed; top:-1em; border:1px
> > > solid black; } label input { -moz-appearance:none;
> > > -webkit-appearance:none; border:none; width:auto; }
> > > input[type=submit] { -moz-appearance:none;
> > > -webkit-appearance:none; background-color:transparent;
> > > border:none; }</style><form action="http://www.google.com/search"
> > > method="get"><label>Search: <input type="text" value=""
> > > name="q"></label><input type=submit value="Go">
> > >
> > > Imagine that was the UA default stylesheet instead of an author
> > > stylesheet and you may see what interoperability means with web
> > > application look and feel.
> >
> > Indeed it would be a problem if a major web browser shipped with such a
> > default style-sheet. But ... I'm really having trouble imagining any of
> > them doing so.  It isn't in mainstream browsers' interests to produce
> > products which purposefully confuse their users.
> >
> > Surely a browser which disguises buttons as plain text is going to lose
> > market share of its own accord, regardless of what HTML 5 says?
> 
> 
> > Or, to look at it from the opposite direction, supposing a browser
> > producer really wanted to make buttons look like plain text, would
> > whether HTML 5 condemns this practice really affect what they do?  Would
> > not being able to market their browser as HTML-5-compliant be enough
> > that they'd begrudgingly forget their desire?  Would users dissatisfied
> > with the behaviour only complain because it breaches HTML 5, rather than
> > because, say, it's really stupid?
> >
> > I can't see how a requirement such as you propose would make any
> > practical difference on avoiding the outcomes you wish to avoid.  But it
> > might unnecessarily curtail innovation in directions that we haven't yet
> > envisaged -- perhaps somebody developing a specialist user-agent for
> > mobile devices (or digital TV, or for print-based output, or
> > large-screen non-interactive displays, or ...) comes up with a different
> > way of displaying certainly elements which she considers is superior for
> > her particular target audience; why should the spec attempt to dissuade
> > her from doing so?
> >
> > Smylers
> >
> 
> I agree with you that we must not constrain the innovation, but in that
> case, what is the whole purpose of the Rendering section?
> I think that section is for
> - implementors of new UAs, that don't need to reverse engineer the
> competitor products in order to find the defaults

Yup -- it means that somebody creating a conventional graphical web
browser can straightforwardly produce the output of other such web
browsers, and that authors expect.

> - authors, that in this way know what to expect from the various UA

Yes.  But note that expectations are merely that; expectations are not
always met!  And there may well be instances in which a user-agent for a
particular market decides to different rendering would better suit that
market; users of such a device are likely to appreciate it -- and
whether the author expected it (or even became aware of it) doesn't
necessarily matter.

> Having somewhere written that hyperlinks should be blue, allows you to
> style the background-color to anything but blue.  If the UA suddenly
> displays hyperlinks in green and I decided that my background is
> green, the user will complain with me,

Indeed.  That's precisely why they should only be labelled as
expectations and not things an author can rely on.  The only sane
options for an author are to set no colours at all or to specify both
background and text colours.  It is not safe only to set one of them,
and it would be irresponsible for HTML 5 to give the impression that it
is.

(Remember that even if all browsers implement the provided defaults,
users can still set a preference of green links or whatever.)

> The solutions are two:
> 1) either provide a default style sheets only for author and say: "you
> want the usual rendering everywhere? import this". This means that the
> whole Rendering sections should be moved to an Appendix and a separate
> downloadable CSS file should be provided.

That's very close to what we have got.

Except that it isn't in an appendix; it's in a non-normative section.
But the important point is that it isn't normative.

And that a browser producer is permitted to choose to implement them by
default rather than expecting users to have to import them.

Consider if a future release of Firefox didn't contain the CSS for
expected web rendering, but users could import it should they want to.
It turns out that nearly all users desire this rendering; this new
Firefox release and they find it tedious to have to specify it
separately (if indeed they are technical enough to have discovered how
to do so; many simply consider that Firefox release to be broken).

So somebody takes the Firefox source code, adds in the default user
styles, and releases it as Snowchicken.  Most users prefer Snowchicken
over Firefox, so Snowchicken gains market share.

Are you suggesting that it would be better for Snowchicken to be deemed
_not_ to comply to HTML 5 because it includes this default styling that
you wanted to be only for users?

If so, please can you explain what the advantages are.

If not, and you believe Snowchicken should still comply, please can you
explain how your preferred situation differs from what's current in the
spec.

Smylers


From bhawkeslewis at googlemail.com  Sun Feb  8 09:44:06 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Sun, 08 Feb 2009 17:44:06 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902080518x4c6ad12do3570775d02d884c1@mail.gmail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>	
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>	
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>	
	<498DD687.7060303@googlemail.com>	
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>	
	<498DE005.2070502@googlemail.com>	
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>	
	<498E259B.3010300@googlemail.com>
	<65307430902080518x4c6ad12do3570775d02d884c1@mail.gmail.com>
Message-ID: <498F19E6.80203@googlemail.com>

On 8/2/09 13:18, Giovanni Campagna wrote:
> 2009/2/8 Benjamin Hawkes-Lewis <bhawkeslewis at googlemail.com
> <mailto:bhawkeslewis at googlemail.com>>
>
>     On 7/2/09 20:07, Giovanni Campagna wrote:
>
>         Yes, but what properties should I query for?
>
>
>     In order to find out what, precisely?
>
> What to reset, for example (see the first Ian email on this topic)

I don't follow. What to reset when in order to achieve what?

>     Their values depend on user agent defaults (which may be anything),
>     user preferences (which may be anything), user stylesheets (which
>     may be anything), and publisher styles (which may be anything), as
>     per the CSS cascade:
>
> I am the author, so at least those values are known.

Well, that's more-or-less true although in practice you don't know what 
CSS properties and values the UA implements, so you don't know which it 
actually would apply even without a user stylesheet.

> So the only properties I may find useful to know the values
> are UA default, that should be consistent across different platform and
> browser.

I disagree that they "should" be consistent, though obviously there are 
market pressures towards making them so and it's helpful to have a 
specification for mimicking common presentation.

>     http://www.w3.org/TR/CSS21/cascade.html#cascade
>
>     In other words, the values cannot be known for sure until you query
>     them.
>
>     Even if you mandated precise user agent defaults, the values still
>     could not be known for sure until you queried them, because of user
>     preferences, user stylesheets, and publisher styles.
>
>
> If you mandate strict UA default, and the publisher (I repeat, I am the
> author, I know what I write) overrides them, he may be sure that: either
> it will look as no default style applied at all, or any additional
> property that applies has been set by the user (so it is not my problem,
> he wanted all the <a>s to be purple on yellow background, even if it
> looks horrible to me)

That's true (except for the practical support problem mentioned above), 
but that's different to knowing the applied value.

>     There's a recursion problem there.
>
>     User agents may derive the effects of "appearance" from user-agent
>     default stylesheets:
>
>     http://www.w3.org/TR/css3-ui/#appearance
>
>
> UA must derive the appearance effects from the user agent skin, widgets
> theme or native platform widgets (ie the common controls on win or the
> Gtk / Qt themes in Linux). Those settings are not part of the UA default
> style sheet, are not necessarily expressed in CSS, and do not take part
> in the cascade.

The draft specification for "appearance" says:

"This specification does not define the term 'platform'.

"For example, it could be the native graphical rendering engine of the 
operating system, or it could be a user-agent-specific skin."

As far as I can see, there's nothing in the spec to prevent the 
"user-agent-specific skin" being expressed as a user-agent default 
stylesheet, or to prevent a user-agent developer interpreting "platform" 
as equivalent to the user-agent default stylesheet.

If there is something, please cite it.

>         HTML5 should not mandate the UA present <a>s in blue, but it should
>         mandate the UA present <a>s like links (appearance:hyperlink).
>
>
>     How would you test whether a UA complied with that requirement or
>     not? Purely by testing the value of the appearance property applied
>     to the element with a default configuration?
>
> 1) you test the conformance to HTML5 by testing the value of appearance
> and the semantics of the element (it must be an hyper-link, if you want
> normative rendering or not)
> 2) you test the conformance to CSS3 UI by testing the look and feel of
> the elements, and comparing it to the standard look and feel for that
> platform, skin, them, etc.

I think the lack of definition of "platform" probably makes (2) 
untestable, and that undermines the value of (1).

--
Benjamin Hawkes-Lewis







From bhawkeslewis at googlemail.com  Sun Feb  8 09:50:27 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Sun, 08 Feb 2009 17:50:27 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>	<498DD687.7060303@googlemail.com>	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>	<498DE005.2070502@googlemail.com>	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
Message-ID: <498F1B63.5030603@googlemail.com>

On 8/2/09 14:38, Giovanni Campagna wrote:
> Having somewhere written that hyperlinks should be blue, allows you to
> style the background-color to anything but blue.
> If the UA suddenly displays hyperlinks in green and I decided that my
> background is green, the user will complain with me, not with the UA
> (and will probably switch to a different website)

I'm confused by this example. Didn't you already agree that HTML5 should 
*not* specify colors for links?

"HTML5 should not mandate the UA present <a>s in blue, but it should 
mandate the UA present <a>s like links (appearance:hyperlink). The color 
of course is a matter of visual themes and platform."

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018408.html

--
Benjamin Hawkes-Lewis


From robert at ocallahan.org  Sun Feb  8 17:25:12 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 9 Feb 2009 14:25:12 +1300
Subject: [whatwg] Error in the play() method's algorithm
Message-ID: <11e306600902081725h132babbboca99b391bbd584d6@mail.gmail.com>

http://www.whatwg.org/specs/web-apps/current-work/#dom-media-play
Step 3.3 says "Otherwise, the media element's readyState attribute has the
value HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA"...

But this isn't true. It could be HAVE_NOTHING, in fact it will often be
HAVE_NOTHING, because if the network state was NETWORK_EMPTY when play() is
called, then the load() method will have returned with the readyState set to
HAVE_NOTHING.

I suspect the description of play() needs to be updated to account for the
change to make load() asynchronous.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090209/d054612b/attachment.htm>

From robert at ocallahan.org  Sun Feb  8 18:22:31 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 9 Feb 2009 15:22:31 +1300
Subject: [whatwg] Small inconsistencies in video events
Message-ID: <11e306600902081822m7a71d1adif6ddf7de667c1073@mail.gmail.com>

I was just writing some tests for various events and noticed that there's a
slight weirdness in the events fired for readyState transitions. If
readyState changes from HAVE_CURRENT_DATA to HAVE_FUTURE_DATA, the element
is then potentially playing, and then readyState changes to
HAVE_ENOUGH_DATA, we fire "canplay", "playing", "canplay" again,
"canplaythrough" and "playing" again. OTOH if readyState changes from
HAVE_CURRENT_DATA directly to HAVE_ENOUGH_DATA and the element is
potentially playing, then we fire "canplay", "canplaythrough", and
"playing".

I think we should fire the same set of events in the same order whether we
transition through HAVE_FUTURE_DATA or not. So, I suggest that a transition
from HAVE_FUTURE_DATA to HAVE_ENOUGH_DATA should not fire "canplay" or
"playing". Also, a transition from HAVE_CURRENT_DATA to HAVE_ENOUGH_DATA
should fire "canplaythrough" after we've handled autoplay and potentially
fired "playing".

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090209/93228aa6/attachment.htm>

From dhtmlkitchen at gmail.com  Sun Feb  8 21:15:36 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Sun, 8 Feb 2009 21:15:36 -0800
Subject: [whatwg] defer on style, depends
Message-ID: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>

Sometimes a document's resources are not needed all at first. For
example, a script that is not needed until after the document is
parsed can be given the defer attribute (for browsers that support
defer).

External css can also be a blocking download. Scripts have defer
attribute, but style and link do not.

The proposal is to add to defer to style, and link.

This will allow browsers to not block on those elements.

It would be more complete to have a depends attribute on script and style.

<script depends="a b c"></script>

Where the depends is id-list [CS], space separated values of element IDs.

It would also be useful to have a way to dynamically load scripts,
other than createElement("script").

Garrett


From ian at hixie.ch  Sun Feb  8 21:20:17 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 9 Feb 2009 05:20:17 +0000 (UTC)
Subject: [whatwg] defer on style, depends
In-Reply-To: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>

On Sun, 8 Feb 2009, Garrett Smith wrote:
>
> Sometimes a document's resources are not needed all at first. For 
> example, a script that is not needed until after the document is parsed 
> can be given the defer attribute (for browsers that support defer).
> 
> External css can also be a blocking download. Scripts have defer 
> attribute, but style and link do not.
> 
> The proposal is to add to defer to style, and link.
> 
> This will allow browsers to not block on those elements.

Browsers are already allowed to not block on those elements.


> It would be more complete to have a depends attribute on script and style.
> 
> <script depends="a b c"></script>
> 
> Where the depends is id-list [CS], space separated values of element IDs.

Why can't you just put the <script> element below the elements whose IDs 
you would have listed?


> It would also be useful to have a way to dynamically load scripts, other 
> than createElement("script").

This seems like a request for the ECMAScript group.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From jonas at sicking.cc  Sun Feb  8 23:26:08 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Sun, 8 Feb 2009 23:26:08 -0800
Subject: [whatwg] defer on style, depends
In-Reply-To: <Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
Message-ID: <63df84f0902082326x4aeabbd9vef737256dc424fd@mail.gmail.com>

On Sun, Feb 8, 2009 at 9:20 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Sun, 8 Feb 2009, Garrett Smith wrote:
>>
>> Sometimes a document's resources are not needed all at first. For
>> example, a script that is not needed until after the document is parsed
>> can be given the defer attribute (for browsers that support defer).
>>
>> External css can also be a blocking download. Scripts have defer
>> attribute, but style and link do not.
>>
>> The proposal is to add to defer to style, and link.
>>
>> This will allow browsers to not block on those elements.
>
> Browsers are already allowed to not block on those elements.

Well, Garrett is somewhat correct. For example in the following scenario:

<link rel=stylesheet href="external.css">
<script>
  doStuff();
</script>

In gecko, when we parse the <script> tag, we'll block until all
external stylesheets have finished loading before we start executing
the script. This is because the script might be getting .offsetLeft or
calling .getComputedStyle or some such, which uses style data. We have
found that some sites break if we just use whatever style data happens
to have loaded at that point, rather than ensuring that all
stylesheets have been parsed and applied.

I think at least some other browsers behave similarly.

However adding a 'defer' attribute to the style link seems like an odd
fix as nothing is actually deferred. You very rarely actually want to
defer stylesheet loading as you generally want to show content with
stylesheets applied. Unstyled content tends to at best be ugly, at
worst be totally nonsensical.

A more logical fix would be to add an attribute to the <script> in
question, indicating that the script can be executed without waiting
for all stylesheets to load. Though that can be very painful to add to
all scripts in the page. Possibly a page-wide attribute or API would
better solve this problem. Though I'm not really a fan of either of
those solutions either.

/ Jonas


From ian at hixie.ch  Mon Feb  9 00:23:37 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 9 Feb 2009 08:23:37 +0000 (UTC)
Subject: [whatwg] defer on style, depends
In-Reply-To: <63df84f0902082326x4aeabbd9vef737256dc424fd@mail.gmail.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com> 
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
	<63df84f0902082326x4aeabbd9vef737256dc424fd@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902090820380.952@hixie.dreamhostps.com>

On Sun, 8 Feb 2009, Jonas Sicking wrote:
> >>
> >> This will allow browsers to not block on those elements.
> >
> > Browsers are already allowed to not block on those elements.
> 
> Well, Garrett is somewhat correct. For example in the following 
> scenario:
> 
> <link rel=stylesheet href="external.css">
> <script>
>   doStuff();
> </script>
> 
> In gecko, when we parse the <script> tag, we'll block until all external 
> stylesheets have finished loading before we start executing the script. 
> This is because the script might be getting .offsetLeft or calling 
> .getComputedStyle or some such, which uses style data. We have found 
> that some sites break if we just use whatever style data happens to have 
> loaded at that point, rather than ensuring that all stylesheets have 
> been parsed and applied.

Yes, external CSS can cause <script> elements to block on the CSS.


> However adding a 'defer' attribute to the style link seems like an odd 
> fix as nothing is actually deferred. You very rarely actually want to 
> defer stylesheet loading as you generally want to show content with 
> stylesheets applied. Unstyled content tends to at best be ugly, at worst 
> be totally nonsensical.
> 
> A more logical fix would be to add an attribute to the <script> in 
> question, indicating that the script can be executed without waiting for 
> all stylesheets to load. Though that can be very painful to add to all 
> scripts in the page. Possibly a page-wide attribute or API would better 
> solve this problem. Though I'm not really a fan of either of those 
> solutions either.

I'm not convinced either of these are really great solutions. I think it'd 
be better just to have the script itself only block when it hits 
CSS-dependent APIs (though I recognise that that is a much harder problem 
in most rendering engines today).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From dhtmlkitchen at gmail.com  Mon Feb  9 00:25:09 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 9 Feb 2009 00:25:09 -0800
Subject: [whatwg] defer on style, depends
In-Reply-To: <Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
Message-ID: <c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>

On Sun, Feb 8, 2009 at 9:20 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Sun, 8 Feb 2009, Garrett Smith wrote:
>>
>> Sometimes a document's resources are not needed all at first. For
>> example, a script that is not needed until after the document is parsed
>> can be given the defer attribute (for browsers that support defer).
>>
>> External css can also be a blocking download. Scripts have defer
>> attribute, but style and link do not.
>>
>> The proposal is to add to defer to style, and link.
>>
>> This will allow browsers to not block on those elements.
>
> Browsers are already allowed to not block on those elements.
>

But they do.

If a script occurs after a link, the script expects updated style
information. That is why browsers do block on scripts.

http://dhtmlkitchen.com/jstest/block/link.html

Includes a linked stylesheet that is delayed by 5 seconds.

Results:
contentLoaded: ~5101
onloadFired: ~5101

That result shows that I am correct on this matter.

>
>> It would be more complete to have a depends attribute on script and style.
>>
>> <script depends="a b c"></script>
>>
>> Where the depends is id-list [CS], space separated values of element IDs.
>
> Why can't you just put the <script> element below the elements whose IDs
> you would have listed?
>

An associated script might need that stylesheet to be loaded before it
runs. The depends attribute would guarantee that the stylesheet had
loaded. The order should not change because the script is an inline
scripts vs an external resource.

A deferred stylesheet could be used to load a stylesheet after content
was parsed. The developer would use defer when FOUC would be known not
to occur as a result. For example, defer would be useful for an
infoPanel widget that did not get shown until a certain event. The
widget's HTML exists in the source code, towards the bottom, the
script appears below that, just before the closing </body> tag.

There is a second problem: The problem of scripts being blocked by a stylesheet.

The "depends=" attribute allows the script to declare that it needs
style information first. This would be a much better design, and could
probably be implemented by the browser with some nice event-driven
code. Unfortunately, implementations that encounter <link defer
type="text/css"...>, followed by a script with no "depends" would
still have to block on that stylesheet because that is what they do
today.

The script could declare itself as "independent".

That would result in links not blocking.

To allow the stylesheet to load after all content loads, the
stylesheet could declare defer:

<link defer src="deferred-all-min.css" type="text/css"
rel="stylesheet" id="lateBoundCSS">

To fulfill a requirement of having loaded of the stylesheet before the
script runs, that script could declare depends to declare that it
needs style information before loading.

<script defer depends="lateBoundCSS" src="app-all-min.js"></script>

>
>> It would also be useful to have a way to dynamically load scripts, other
>> than createElement("script").
>
> This seems like a request for the ECMAScript group.
>

Maybe. I would probably not be able to use it before I retire.

It could also be a DOM document method.

var script = document.createScript(src);
script.load();
script.run();
script.unload();

A script belongs to a document. ECMAScript has no notion of document.
Scripts loaded through this mechanism would ignore document.write.

Applications could see a performance boost if developers could
leverage such features.

Garrett

> Cheers,
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>


From ian at hixie.ch  Mon Feb  9 02:26:31 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 9 Feb 2009 10:26:31 +0000 (UTC)
Subject: [whatwg] defer on style, depends
In-Reply-To: <c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com> 
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com>

On Mon, 9 Feb 2009, Garrett Smith wrote:
> On Sun, Feb 8, 2009 at 9:20 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Sun, 8 Feb 2009, Garrett Smith wrote:
> >>
> >> Sometimes a document's resources are not needed all at first. For 
> >> example, a script that is not needed until after the document is 
> >> parsed can be given the defer attribute (for browsers that support 
> >> defer).
> >>
> >> External css can also be a blocking download. Scripts have defer 
> >> attribute, but style and link do not.
> >>
> >> The proposal is to add to defer to style, and link.
> >>
> >> This will allow browsers to not block on those elements.
> >
> > Browsers are already allowed to not block on those elements.
> 
> But they do.
> 
> If a script occurs after a link, the script expects updated style 
> information. That is why browsers do block on scripts.

They block on scripts, yes. (Not on style.)

See my reply to Jonas for further discussion of this matter.


> >> It would be more complete to have a depends attribute on script and 
> >> style.
> >>
> >> <script depends="a b c"></script>
> >>
> >> Where the depends is id-list [CS], space separated values of element 
> >> IDs.
> >
> > Why can't you just put the <script> element below the elements whose 
> > IDs you would have listed?
> 
> An associated script might need that stylesheet to be loaded before it 
> runs. The depends attribute would guarantee that the stylesheet had 
> loaded. The order should not change because the script is an inline 
> scripts vs an external resource.

It seems pretty simple to me; if you want the style to be loaded when the 
script runs, put the style first. If you don't, put the script first and 
defer it (or mark it async). Why should this not be enough?


> The "depends=" attribute allows the script to declare that it needs 
> style information first. This would be a much better design, and could 
> probably be implemented by the browser with some nice event-driven code. 
> Unfortunately, implementations that encounter <link defer 
> type="text/css"...>, followed by a script with no "depends" would still 
> have to block on that stylesheet because that is what they do today.
> 
> The script could declare itself as "independent".
> 
> That would result in links not blocking.
> 
> To allow the stylesheet to load after all content loads, the stylesheet 
> could declare defer:
> 
> <link defer src="deferred-all-min.css" type="text/css" rel="stylesheet" 
> id="lateBoundCSS">
> 
> To fulfill a requirement of having loaded of the stylesheet before the 
> script runs, that script could declare depends to declare that it needs 
> style information before loading.
> 
> <script defer depends="lateBoundCSS" src="app-all-min.js"></script>

This seems like an inordinate amount of complexity for something that can 
just work already.


> >> It would also be useful to have a way to dynamically load scripts, 
> >> other than createElement("script").
> >
> > This seems like a request for the ECMAScript group.
> 
> Maybe. I would probably not be able to use it before I retire.

We should not design specifications around the characteristics of the 
committees. If you have a problem with the ECMAScript group, I urge you to 
bring it to their attention. This forum is inappropriate for such 
discussion.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From t.broyer at gmail.com  Mon Feb  9 03:46:45 2009
From: t.broyer at gmail.com (Thomas Broyer)
Date: Mon, 9 Feb 2009 12:46:45 +0100
Subject: [whatwg] defer on style, depends
In-Reply-To: <Pine.LNX.4.62.0902090820380.952@hixie.dreamhostps.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
	<63df84f0902082326x4aeabbd9vef737256dc424fd@mail.gmail.com>
	<Pine.LNX.4.62.0902090820380.952@hixie.dreamhostps.com>
Message-ID: <a9699fd20902090346m8e2e696x124abc285737527b@mail.gmail.com>

On Mon, Feb 9, 2009 at 9:23 AM, Ian Hickson wrote:
>
> I'm not convinced either of these are really great solutions. I think it'd
> be better just to have the script itself only block when it hits
> CSS-dependent APIs (though I recognise that that is a much harder problem
> in most rendering engines today).

Dave Hyatt blogged about exactly this more than 2 years ago:
http://webkit.org/blog/66/the-fouc-problem/

-- 
Thomas Broyer


From scampa.giovanni at gmail.com  Mon Feb  9 05:53:35 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Mon, 9 Feb 2009 14:53:35 +0100
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <498F1B63.5030603@googlemail.com>
References: <65307430902060954m5bd2c76ale51adb6db4d75040@mail.gmail.com>
	<Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
	<498F1B63.5030603@googlemail.com>
Message-ID: <65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>

@Smylers:

So the whole rendering section is just for implementors and authors should
act if no default style sheet is present or worse, if it could be
everything, like a inline-block <div> or blue <table>, so that the author
should set all supported properties to initial or the HTML5 "expected"
value?
That is:
I, author, want consistent rendering on all plaforms and browser: I import
the HTML5 style sheet inside author ones.
I, implementor, want to provide backward-compatible rendering for those
author that didn't follow rule 1), I import HTML5 style sheet inside UA
defaults.
In both case, a downloadable stylesheet would be much appreciated.

@Benjamin:

1) Ian initially said that they chose the binding property (instead of
specifying appearance, border, color, etc.)  in order to allow easy
resetting of default look-and-feel for widgets
2) I thought that author could make assumptions about the default CSS,
Smylers convinced me that this cannot be true
3) at least in that case I know that if web site doesn't work, it is not my
fault, but user's. But this has a major flaw:
"customer is always right". In addition, once again, I was convinced that
you can't make assumption on UA rendering.
4)
input[type=text] {
border:1px solid blue;
font: "Arial" 10pt;
user-input: enabled;
user-modify: read-write;
cursor: url(I-beam.png);
}

looks different than

@appearance field {
border:1px solid ThreeDFace;
font:field;
user-input:enabled;
user-modify: read-write;
cursor: text;
}
@sys-color ThreeDFace rgb(0,0,255);
@sys-font field {
font-family: "Arial";
font-size: 10pt;
}
@sys-cursor text {
src: url(I-beam.png);
}
input[type=text] {
appearance:field;
}

assuming three imaginary at-rules to define UA skin at CSS level.

5) I agree with you, it may be impossible

6) either HTML5 defines everything, or it defines nothing

Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090209/09f39d12/attachment.htm>

From Smylers at stripey.com  Mon Feb  9 06:24:19 2009
From: Smylers at stripey.com (Smylers)
Date: Mon, 9 Feb 2009 14:24:19 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
References: <Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
	<498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
Message-ID: <20090209142419.GA2461@stripey.com>

Giovanni Campagna writes:

> So the whole rendering section is just for implementors and authors
> should act if no default style sheet is present

No; the section is also for authors, in that it advises them of how
content is expected to be rendered in mainstream graphical browsers.

> or worse, if it could be everything, like a inline-block <div> or blue
> <table>,

Indeed it _could_ be anything, but there's no reason for authors to be
worried about that; if a (non-malicious) user-agent does something
different from that expected by HTML 5 then it presumably has done so
intentionally and it wouldn't necessarily benefit users for authors to
attempt to combat it.

> so that the author should set all supported properties to initial or
> the HTML5 "expected" value?

Not necessarily.

> That is: I, author, want consistent rendering on all plaforms and
> browser:

I think that's where you're going wrong.  Platforms themselves aren't
consistent -- in things like screen sizes, resolutions, distance between
screen and audience, whether they are interactive, what input devices
are available, pagination.

If an esoteric platform chooses to divert from the expected HTML 5
rendering then it's likely because that platform knows more about what
rendering is appropriate for that platform that you do.

> I import the HTML5 style sheet inside author ones.

That's a very parochial view.

In mainstream graphical browsers such importing would be redundant,
because they'll have the expected behaviour anyway.

In esoteric user-agents you cannot know that the HTML 5 defaults provide
a better user experience than those chosen by the user-agents'
developers.

> I, implementor, want to provide backward-compatible rendering for
> those author that didn't follow rule 1), I import HTML5 style sheet
> inside UA defaults.  In both case, a downloadable stylesheet would be
> much appreciated.

I think a downloadable style-sheet is inevitable!

Smylers


From Smylers at stripey.com  Mon Feb  9 06:24:19 2009
From: Smylers at stripey.com (Smylers)
Date: Mon, 9 Feb 2009 14:24:19 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
References: <Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<65307430902070622x66b7bf83v6a7cf947cf3f35a8@mail.gmail.com>
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
	<498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
Message-ID: <20090209142419.GA2461@stripey.com>

Giovanni Campagna writes:

> So the whole rendering section is just for implementors and authors
> should act if no default style sheet is present

No; the section is also for authors, in that it advises them of how
content is expected to be rendered in mainstream graphical browsers.

> or worse, if it could be everything, like a inline-block <div> or blue
> <table>,

Indeed it _could_ be anything, but there's no reason for authors to be
worried about that; if a (non-malicious) user-agent does something
different from that expected by HTML 5 then it presumably has done so
intentionally and it wouldn't necessarily benefit users for authors to
attempt to combat it.

> so that the author should set all supported properties to initial or
> the HTML5 "expected" value?

Not necessarily.

> That is: I, author, want consistent rendering on all plaforms and
> browser:

I think that's where you're going wrong.  Platforms themselves aren't
consistent -- in things like screen sizes, resolutions, distance between
screen and audience, whether they are interactive, what input devices
are available, pagination.

If an esoteric platform chooses to divert from the expected HTML 5
rendering then it's likely because that platform knows more about what
rendering is appropriate for that platform that you do.

> I import the HTML5 style sheet inside author ones.

That's a very parochial view.

In mainstream graphical browsers such importing would be redundant,
because they'll have the expected behaviour anyway.

In esoteric user-agents you cannot know that the HTML 5 defaults provide
a better user experience than those chosen by the user-agents'
developers.

> I, implementor, want to provide backward-compatible rendering for
> those author that didn't follow rule 1), I import HTML5 style sheet
> inside UA defaults.  In both case, a downloadable stylesheet would be
> much appreciated.

I think a downloadable style-sheet is inevitable!

Smylers


From scampa.giovanni at gmail.com  Mon Feb  9 07:51:22 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Mon, 9 Feb 2009 16:51:22 +0100
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <20090209142419.GA2461@stripey.com>
References: <Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
	<498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
	<20090209142419.GA2461@stripey.com>
Message-ID: <65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>

2009/2/9 Smylers <Smylers at stripey.com>

> Giovanni Campagna writes:
>
> > So the whole rendering section is just for implementors and authors
> > should act if no default style sheet is present
>
> No; the section is also for authors, in that it advises them of how
> content is expected to be rendered in mainstream graphical browsers.
>
> > or worse, if it could be everything, like a inline-block <div> or blue
> > <table>,
>
> Indeed it _could_ be anything, but there's no reason for authors to be
> worried about that; if a (non-malicious) user-agent does something
> different from that expected by HTML 5 then it presumably has done so
> intentionally and it wouldn't necessarily benefit users for authors to
> attempt to combat it.

The fact is that could lead to mixtures (part of UA stylesheets and part of
author style sheets) caused by the cascade mechanism that cannot integrate
themselves.

> so that the author should set all supported properties to initial or

> the HTML5 "expected" value?

Not necessarily.

> That is: I, author, want consistent rendering on all plaforms and

> browser:

I think that's where you're going wrong.  Platforms themselves aren't

consistent -- in things like screen sizes, resolutions, distance between

screen and audience, whether they are interactive, what input devices

are available, pagination.


>From the same CSS, you cannot get different results in different browsers or
platforms (unless the browser are not complying with CSS). Content may be
scaled, wrapped, clipped, overflowed, but it will always be the same. A
mobile browser should be different than a resized Firefox window. (Actually,
IE in Windows Mobile / CE is like IE in Windows XP / Vista, just with a
smaller viewport. The same applies for Safari in the iPhone or in Mac OS).
In addition, you can have digital pens also in desktop PC, but you expect
that your browser renders in the same way.

>
>
> If an esoteric platform chooses to divert from the expected HTML 5
> rendering then it's likely because that platform knows more about what
> rendering is appropriate for that platform that you do.
>
I'm not sure the UA knows better than me how to render my web site, because
this would mean it knows how to render every website in the whole world,
better than its own author. It may know better than me how to render
specific parts of it (ie widgets), but not all of it.


> > I import the HTML5 style sheet inside author ones.
>
> That's a very parochial view.
>
> In mainstream graphical browsers such importing would be redundant,
> because they'll have the expected behaviour anyway.

Can I assume they'll have the expected behaviour? No I cannot, because HTML5
explictly says that UAs may render in every way they like.

>
> In esoteric user-agents you cannot know that the HTML 5 defaults provide
> a better user experience than those chosen by the user-agents'
> developers.
>
But I can know that it cannot provide a worse user experience, because, as I
said, given a CSS and a media type (screen - interactive - visual), the
rendering is always the same. Maybe scaled, wrapped, overflowed, but always
the same. (yellow is still yellow, overflow: scroll still produces scrolling
mechanisms, display:table renders a table, width:auto is like width:100% in
non-floated non-positioned block-level elements, etc.)


> > I, implementor, want to provide backward-compatible rendering for
> > those author that didn't follow rule 1), I import HTML5 style sheet
> > inside UA defaults.  In both case, a downloadable stylesheet would be
> > much appreciated.
>
> I think a downloadable style-sheet is inevitable!

Then let's wait for Ian to write one.

>
> Smylers
>
Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090209/53898cd7/attachment.htm>

From bzbarsky at MIT.EDU  Mon Feb  9 08:23:45 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 09 Feb 2009 11:23:45 -0500
Subject: [whatwg] defer on style, depends
In-Reply-To: <Pine.LNX.4.62.0902090820380.952@hixie.dreamhostps.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>	<63df84f0902082326x4aeabbd9vef737256dc424fd@mail.gmail.com>
	<Pine.LNX.4.62.0902090820380.952@hixie.dreamhostps.com>
Message-ID: <49905891.3080802@mit.edu>

Ian Hickson wrote:
> I'm not convinced either of these are really great solutions. I think it'd 
> be better just to have the script itself only block when it hits 
> CSS-dependent APIs (though I recognise that that is a much harder problem 
> in most rendering engines today).

I'm not sure how you envision this working.  The run-to-completion 
semantics mean that while the script is working on the API call to 
return (which means that network events are being processed, etc), the 
following invariants need to be maintained (list very much not exhaustive):

1)  No setTimeout timers fire.
2)  No XMLHttpRequest state changes happen.
3)  No image load events fire.
4)  No stylesheet load events fire (for UAs that implement such an
     event on their <link> elements, as Gecko would like to do).
5)  No user interaction with the page or other pages that can reach the
     given page is allowed.

#5 makes it unlikely that a UA would want to go this route at all.  #4 
means that this approach would be incompatible with reasonable style 
load events...  #1, #2, #3 all mean that networking needs to 
differentiate between the set of stylesheets we're waiting on and 
everything else.

-Boris




From bzbarsky at MIT.EDU  Mon Feb  9 08:26:19 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 09 Feb 2009 11:26:19 -0500
Subject: [whatwg] defer on style, depends
In-Reply-To: <63df84f0902082326x4aeabbd9vef737256dc424fd@mail.gmail.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
	<63df84f0902082326x4aeabbd9vef737256dc424fd@mail.gmail.com>
Message-ID: <4990592B.1080907@mit.edu>

Jonas Sicking wrote:
> Well, Garrett is somewhat correct. For example in the following scenario:
> 
> <link rel=stylesheet href="external.css">
> <script>
>   doStuff();
> </script>
> 
> In gecko, when we parse the <script> tag, we'll block until all
> external stylesheets have finished loading before we start executing
> the script.

Strictly speaking, not quite.  We'll block until all external 
stylesheets in the currently-selected style set have finished loading. 
Alternate stylesheets do not block script execution.  So as of today, 
one can simple use alternate stylesheets for sheets that one does not 
need until end of pageload (though I fail to think of any cases where 
this would be desirable), then change the title/rel when desired.  At 
least in Gecko, this will do what Garrett wants.

-Boris


From dhtmlkitchen at gmail.com  Mon Feb  9 09:35:20 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 9 Feb 2009 09:35:20 -0800
Subject: [whatwg] defer on style, depends
In-Reply-To: <Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>
	<Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com>
Message-ID: <c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>

On Mon, Feb 9, 2009 at 2:26 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 9 Feb 2009, Garrett Smith wrote:
>> On Sun, Feb 8, 2009 at 9:20 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Sun, 8 Feb 2009, Garrett Smith wrote:
>> >>
>> >> Sometimes a document's resources are not needed all at first. For
>> >> example, a script that is not needed until after the document is
>> >> parsed can be given the defer attribute (for browsers that support
>> >> defer).
>> >>
>> >> External css can also be a blocking download. Scripts have defer
>> >> attribute, but style and link do not.
>> >>
>> >> The proposal is to add to defer to style, and link.
>> >>
>> >> This will allow browsers to not block on those elements.
>> >
>> > Browsers are already allowed to not block on those elements.
>>
>> But they do.
>>
>> If a script occurs after a link, the script expects updated style
>> information. That is why browsers do block on scripts.
>
> They block on scripts, yes. (Not on style.)
>
> See my reply to Jonas for further discussion of this matter.
>

If I put the script at the bottom of the page, and a linked stylesheet
in the head, the script waits for the stylesheet.

I want my page to load faster and this feature prevents it.

>
>> >> It would be more complete to have a depends attribute on script and
>> >> style.
>> >>
>> >> <script depends="a b c"></script>
>> >>
>> >> Where the depends is id-list [CS], space separated values of element
>> >> IDs.
>> >
>> > Why can't you just put the <script> element below the elements whose
>> > IDs you would have listed?
>>
>> An associated script might need that stylesheet to be loaded before it
>> runs. The depends attribute would guarantee that the stylesheet had
>> loaded. The order should not change because the script is an inline
>> scripts vs an external resource.
>
> It seems pretty simple to me; if you want the style to be loaded when the
> script runs, put the style first. If you don't, put the script first and
> defer it (or mark it async). Why should this not be enough?
>

The implementation might delayed the page from rendering when it sees
the stylesheet.

The script's defer attribute does not work in a majority of
implementations. For such browsers, it makes sense to put the script
lower on the page for performance reasons, not before the linked
stylesheets. Moving the deferred script from the bottom of the page to
the head, just before the stylesheet would mean that those scripts
would load first. This would prevent the page content from loading
until those scripts had loaded. This would hurt performance in the
majority of browsers in use today.

Putting scripts at the bottom works in all browsers. Including a
linked stylesheet in the head causes delays.

Please see the link that Thomas Broyer provided. See the section "Don't Stall".

Please also visit the example I made last night.

>
>> The "depends=" attribute allows the script to declare that it needs
>> style information first. This would be a much better design, and could
>> probably be implemented by the browser with some nice event-driven code.
>> Unfortunately, implementations that encounter <link defer
>> type="text/css"...>, followed by a script with no "depends" would still
>> have to block on that stylesheet because that is what they do today.
>>
>> The script could declare itself as "independent".
>>
>> That would result in links not blocking.
>>
>> To allow the stylesheet to load after all content loads, the stylesheet
>> could declare defer:
>>
>> <link defer src="deferred-all-min.css" type="text/css" rel="stylesheet"
>> id="lateBoundCSS">
>>
>> To fulfill a requirement of having loaded of the stylesheet before the
>> script runs, that script could declare depends to declare that it needs
>> style information before loading.
>>
>> <script defer depends="lateBoundCSS" src="app-all-min.js"></script>
>
> This seems like an inordinate amount of complexity for something that can
> just work already.
>

Whatever.

>
>> >> It would also be useful to have a way to dynamically load scripts,
>> >> other than createElement("script").
>> >
>> > This seems like a request for the ECMAScript group.
>>
>> Maybe. I would probably not be able to use it before I retire.
>
> We should not design specifications around the characteristics of the
> committees. If you have a problem with the ECMAScript group, I urge you to
> bring it to their attention. This forum is inappropriate for such
> discussion.

You focused on one sentence that I wrote. You misinterpreted what I
wrote. I never ever suggested designing a specification around
committee characteristics. I said:

| A script belongs to a document. ECMAScript has no notion of document.

Lets try to stay on-topic and focused. Thanks.

Garrett


From bzbarsky at MIT.EDU  Mon Feb  9 09:42:18 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 09 Feb 2009 12:42:18 -0500
Subject: [whatwg] defer on style, depends
In-Reply-To: <c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>	<Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com>
	<c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>
Message-ID: <49906AFA.804@mit.edu>

Garrett Smith wrote:
> The script's defer attribute does not work in a majority of
> implementations. For such browsers, it makes sense to put the script
> lower on the page for performance reasons, not before the linked
> stylesheets. Moving the deferred script from the bottom of the page to
> the head, just before the stylesheet would mean that those scripts
> would load first. This would prevent the page content from loading
> until those scripts had loaded. This would hurt performance in the
> majority of browsers in use today.
> 
> Putting scripts at the bottom works in all browsers. Including a
> linked stylesheet in the head causes delays.

I'm not sure why you think that adding features to browsers to work 
around bugs in those same browsers is the right approach.  Would just 
fixing "defer" for scripts fix your issue?


> Whatever.

That's a very cogent and enlightening response, I'm sure, but it seems 
to be going over my head.  Care to explain in terms someone of my 
limited mental ability can understand?

-Boris


From dhtmlkitchen at gmail.com  Mon Feb  9 10:56:33 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 9 Feb 2009 10:56:33 -0800
Subject: [whatwg] defer on style, depends
In-Reply-To: <49906AFA.804@mit.edu>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>
	<Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com>
	<c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>
	<49906AFA.804@mit.edu>
Message-ID: <c9e12660902091056t10eba8d1i91bcb8f9bda3a528@mail.gmail.com>

On Mon, Feb 9, 2009 at 9:42 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Garrett Smith wrote:
>>
>> The script's defer attribute does not work in a majority of
>> implementations. For such browsers, it makes sense to put the script
>> lower on the page for performance reasons, not before the linked
>> stylesheets. Moving the deferred script from the bottom of the page to
>> the head, just before the stylesheet would mean that those scripts
>> would load first. This would prevent the page content from loading
>> until those scripts had loaded. This would hurt performance in the
>> majority of browsers in use today.
>>
>> Putting scripts at the bottom works in all browsers. Including a
>> linked stylesheet in the head causes delays.
>
> I'm not sure why you think that adding features to browsers to work around
> bugs in those same browsers is the right approach.  Would just fixing
> "defer" for scripts fix your issue?
>

There are two/three issues.
1) want to load stylesheets without having scripts block
2) want to load stylesheets later, (infoPanel example)
3) (2), but want to make sure the stylesheet is loaded before the script runs.

(1) <link independent ..> would address the problem.
There is no solution for (2) or (3). Current implementations may try
to parse the script and see if it can run, but such algorithms are
obviously not going to be effective.

In the example,  the document's title changes to bgColor=<something>.
Adding defer to the script does not help. In fact, it makes the
problem worse.

What happens is that the deferred script waits for the link to load,
but blocks content from loading. After the link loads, the script
runs.

Example 1:
<head><title></title>
<link independent type="text/css"  ...>
<script...></script>
I want the browser to:
1) load my stylesheet and then immediately begin to load script in parallel.

Example 2
<head><title></title>
<link defer type="text/css" id="lateBoundCSS" ...>
</head>
<body>
...
<script depends="lateBoundCSS"...></script>
</body>
I want the browser to:
1) defer my linked stylesheet id="lateBoundCSS" until content is rendered
2) render content
3) upon encountering the deferred script, check the depends
4) upon finding Result(3) is "lateBoundCSS", wait for that resource to
finish load before running.

The infoPanel script needs the infoPanel.css stylesheet,
id="lateBoundCSS". The css is only related to that script, it is
useless otherwise.

The user might begin reading, use the search box, use the login box,
or click links in the page. There is no reason why infoPanel.css needs
to be loaded prior to the user doing those things.

>
>> Whatever.
>
> That's a very cogent and enlightening response, I'm sure, but it seems to be
> going over my head.  Care to explain in terms someone of my limited mental
> ability can understand?
>

Boris, you have snipped what I replied to (the part Ian wrote before I
wrote "whatever").

You replied to that out-of-context snip with a loaded question that
seems very sarcastic. I do not think it such sarcasm is appropriate. I
do not think it would be at all productive to answer such questions.

Thanks.

Garrett

> -Boris
>


From bzbarsky at MIT.EDU  Mon Feb  9 11:54:57 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 09 Feb 2009 14:54:57 -0500
Subject: [whatwg] defer on style, depends
In-Reply-To: <c9e12660902091056t10eba8d1i91bcb8f9bda3a528@mail.gmail.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>	
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>	
	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>	
	<Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com>	
	<c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>	
	<49906AFA.804@mit.edu>
	<c9e12660902091056t10eba8d1i91bcb8f9bda3a528@mail.gmail.com>
Message-ID: <49908A11.6070905@mit.edu>

Garrett Smith wrote:
> There are two/three issues.
> 1) want to load stylesheets without having scripts block

Already doable for alternate stylesheets, right?

I assume the use case is a script that wants to modify the DOM 
immediately but doesn't depend on any styling information?  That's a 
property of the script, not the stylesheet, correct?

> 2) want to load stylesheets later, (infoPanel example)

Not sure what this example is, or why this is insufficienty served by, 
say, putting the <link> at the end of the HTML (assuming HTML allowed 
that, of course).

> 3) (2), but want to make sure the stylesheet is loaded before the script runs.

> (1) <link independent ..> would address the problem.

Independent of what?  In case (1) it's the script that doesn't depend on 
the stylesheet, as far as I can see.  The stylesheet just exists.

> Example 1:
> <head><title></title>
> <link independent type="text/css"  ...>
> <script...></script>
> I want the browser to:
> 1) load my stylesheet and then immediately begin to load script in parallel.

That's exactly what Gecko does in this case, for what it's worth.  It 
will load the script in parallel, but won't _execute_ the script until 
the non-alternate stylesheet has loaded.

> Example 2
> <head><title></title>
> <link defer type="text/css" id="lateBoundCSS" ...>

What is the use case for such CSS, exactly?

> 1) defer my linked stylesheet id="lateBoundCSS" until content is rendered
> 2) render content
> 3) upon encountering the deferred script, check the depends
> 4) upon finding Result(3) is "lateBoundCSS", wait for that resource to
> finish load before running.

Is this a common use case?  Would it be sufficient to address it via a 
load handler on <link> so that one could build whatever dependency or 
ordering setup one wants?

> The infoPanel script needs the infoPanel.css stylesheet,
> id="lateBoundCSS". The css is only related to that script, it is
> useless otherwise.

You mean the CSS is not actually used to style the document?

>>> Whatever.
>> That's a very cogent and enlightening response, I'm sure, but it seems to be
>> going over my head.  Care to explain in terms someone of my limited mental
>> ability can understand?
>>
> 
> Boris, you have snipped what I replied to (the part Ian wrote before I
> wrote "whatever").

Yes, because your response wasn't a response to what Ian wrote.  I do 
happen to agree with Ian's opinion there, for what it's worth.  Want to 
try convincing me that I'm wrong?  "Whatever" is not convincing enough, 
sorry.

> You replied to that out-of-context snip with a loaded question that
> seems very sarcastic.

I doesn't just seem.  It _was_ sarcastic.  I have to admit I was 
somewhat at a loss for how else one could respond to someone saying 
"Whatever" in response to a specific technical argument...

> I do not think it such sarcasm is appropriate. I
> do not think it would be at all productive to answer such questions.

That depends on whether you want me to take your proposals seriously. 
If you do, you might want to take concerns raised about said proposals 
seriously.

-Boris



From jeremydo at google.com  Mon Feb  9 13:13:09 2009
From: jeremydo at google.com (Jeremy Doig)
Date: Mon, 9 Feb 2009 13:13:09 -0800
Subject: [whatwg] Video playback quality metric
Message-ID: <35c92870902091313u3c763a20sea0b322a1bf4afdd@mail.gmail.com>

Measuring the rate at which the playback buffer is filling/emptying gives a
fair indication of network goodput, but there does not appear to be a way to
measure just how well the client is playing the video itself. If I have a
wimpy machine behind a fat network connection, you may flood me with HD that
I just can't play very well. The cpu or video card may just not be able to
render the video well.Exposing a metric (eg: Dropped Frame count, rendered
frame rate) would allow sites to dynamically adjust the video which is being
sent to a client [eg: switch the url to a differently encoded file] and
thereby optimize the playback experience.
Anyone else think this would be good to have ?

Thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090209/503ac29b/attachment.htm>

From robert at ocallahan.org  Mon Feb  9 14:27:56 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 10 Feb 2009 11:27:56 +1300
Subject: [whatwg] Video playback quality metric
In-Reply-To: <35c92870902091313u3c763a20sea0b322a1bf4afdd@mail.gmail.com>
References: <35c92870902091313u3c763a20sea0b322a1bf4afdd@mail.gmail.com>
Message-ID: <11e306600902091427x7f90bdeai342466de6d4ed9bc@mail.gmail.com>

On Tue, Feb 10, 2009 at 10:13 AM, Jeremy Doig <jeremydo at google.com> wrote:

> Measuring the rate at which the playback buffer is filling/emptying gives a
> fair indication of network goodput, but there does not appear to be a way to
> measure just how well the client is playing the video itself. If I have a
> wimpy machine behind a fat network connection, you may flood me with HD that
> I just can't play very well. The cpu or video card may just not be able to
> render the video well. Exposing a metric (eg: Dropped Frame count,
> rendered frame rate) would allow sites to dynamically adjust the video which
> is being sent to a client [eg: switch the url to a differently encoded file]
> and thereby optimize the playback experience.
> Anyone else think this would be good to have ?
>

Yes, I do.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090210/df27ab4c/attachment.htm>

From dhtmlkitchen at gmail.com  Mon Feb  9 18:15:32 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Mon, 9 Feb 2009 18:15:32 -0800
Subject: [whatwg] defer on style, depends
In-Reply-To: <49908A11.6070905@mit.edu>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>
	<Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com>
	<c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>
	<49906AFA.804@mit.edu>
	<c9e12660902091056t10eba8d1i91bcb8f9bda3a528@mail.gmail.com>
	<49908A11.6070905@mit.edu>
Message-ID: <c9e12660902091815q3a659cf6q592ab7844f7b179f@mail.gmail.com>

On Mon, Feb 9, 2009 at 11:54 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Garrett Smith wrote:
>>
>> There are two/three issues.
>> 1) want to load stylesheets without having scripts block
>
> Already doable for alternate stylesheets, right?
>

An html document could contain an alternate stylesheet, intended for a
script to change the stylesheet from "alternate".

That would make the code less straightforward. It is going to be
harder for a fresh pair of eyes to understand what is going on.

> I assume the use case is a script that wants to modify the DOM immediately
> but doesn't depend on any styling information?  That's a property of the
> script, not the stylesheet, correct?
>

What do you propose?

A "nodepends" attribute for a script element?

Lets go over what I want the browser to do:

In general, I want better declarative control over loading external
resources. The solution(s) should not cause compatibility problems
with existing browsers (because I have to support IE6 and Firefox 2).

I want the browser to be able to load and run a script without being
in the position of trying to determine if it should wait for
stylesheet data to complete. I've noticed these things hang.

I also want to be able to load and run a script, without having to
resort to a clunky API (createElement('script')).

To declare the script to load and run immediately after the
stylesheets (without depending on the style information), Ian
suggested that I put the script first in the head and use defer.

That will have a negative affect on performance in all browsers that
support defer and the browsers that do not support defer.

In browsers that do not support defer, the scripts must be loaded
before subsequent content is loaded. The scripts will block content
from rendering below. Scripts will also prevent download of linked
stylesheets that appear after in the source. This type of design would
also have a negative effect on browsers that do *not* support defer
because it means that the scripts appear first, before any linked
stylesheets, and cannot be included at the bottom (which is common to
do for performance reasons).

In browsers that do support defer, the script would run *after* the
document parsed, and that would occur after the stylesheet loaded.

Example:
http://dhtmlkitchen.com/jstest/block/link-defer-top.html

We can see that the deferred "alert" external script will run first in
browsers that ignore defer. In browsers that do not ignore defer, it
will run last, after the stylesheet is loaded. Including a deferred
script first will result in an inconsistent execution of that script.
It would requires= a very flexible program design (that may result in
error if not very careful) and for absolutely no benefit.

The result would be bad for performance either way. This was Ian's
advice. It is impractical, error prone, and bad for performance. That
is horrible advice.

>> 2) want to load stylesheets later, (infoPanel example)
>
> Not sure what this example is, or why this is insufficienty served by, say,
> putting the <link> at the end of the HTML (assuming HTML allowed that, of
> course).
>

Are you proposing HTML allow that?

>> 3) (2), but want to make sure the stylesheet is loaded before the script
>> runs.
>
>> (1) <link independent ..> would address the problem.
>
> Independent of what?  In case (1) it's the script that doesn't depend on the
> stylesheet, as far as I can see.  The stylesheet just exists.
>

The script could declare whether it needs such resource by its
"depends=" attribute. However, browsers today delay (some) scripts
from running. Scripts depend on stylesheets; content depends on
scripts and stylesheets. Content can contain more scripts. Omitting
depends for scripts could not possibly solve the problem for browsers
today (because they already depend on stylesheets).

An "independent" attribute on a link says that a browser does not need
to wait for that resource to finish loading before it loads other
resources (like loading a script). When the parser parses that
"independent" attribute, it sets a flag for the browser go ahead and
download and run any subsequent script.

A "nodepends" type attribute on a script would work, too. I like that
idea, though it does mean the browser has to do some lookahead (then
again, apparently they already do).

>> Example 1:
>> <head><title></title>
>> <link independent type="text/css"  ...>
>> <script...></script>
>> I want the browser to:
>> 1) load my stylesheet and then immediately begin to load script in
>> parallel.
>
> That's exactly what Gecko does in this case, for what it's worth.  It will
> load the script in parallel, but won't _execute_ the script until the
> non-alternate stylesheet has loaded.
>

For a script in the head, that is what Gecko and Webkit will do.
However, external resources such as SCRIPT or IMG that appear in the
BODY will not get requested by the browser until the page content
renders. That is actually a good argument for *not* moving scripts to
before the closing body tag.

In both cases (head script or body script), the browser will not
execute the script until the stylesheet is downloaded. It won't render
content that occurs after the script until the script is executed.

So what we have here is a daisy chain. Content depends on Script
depends on Style. That is very crude order of affairs and offers the
developer little control over load order.

For example:
http://localhost/jstest/block/link-defer.html

In Safari 3.1,content is rendered after 5 seconds. After 5 seconds, I see:
contentLoaded: 2
onloadFired: 5008

In this case, I want the script to in the head to download and execute
without waiting for the css.

to fulfill example 2, I would defer the stylesheet, and declare the
script at the end depends on it. Before that script could run, the
stylesheet would need to be loaded. Since the linked stylesheet is
deferred, the body content would render and not be blocked by the
linked stylesheet loading. I don't know if it would be possible to
optimize reflow for that, or if it would be possible to "scope" the
stylesheet somehow.

>> Example 2
>> <head><title></title>
>> <link defer type="text/css" id="lateBoundCSS" ...>
>
> What is the use case for such CSS, exactly?
>

A deferred stylesheet could be used for styling hidden elements that
will be shown, or components that are created in javascript.

This would allow the browser to render content before the process of
applying that style information.

Question: When the stylesheet is eventually applied, could the reflow
be optimized for performance?

>> 1) defer my linked stylesheet id="lateBoundCSS" until content is rendered
>> 2) render content
>> 3) upon encountering the deferred script, check the depends
>> 4) upon finding Result(3) is "lateBoundCSS", wait for that resource to
>> finish load before running.
>
> Is this a common use case?  Would it be sufficient to address it via a load
> handler on <link> so that one could build whatever dependency or ordering
> setup one wants?
>

That would put the css information in the script and make the document
source harder to understand. It clutters up the script and is even
messier than adding a "nodepends" attribute.

>> The infoPanel script needs the infoPanel.css stylesheet,
>> id="lateBoundCSS". The css is only related to that script, it is
>> useless otherwise.
>
> You mean the CSS is not actually used to style the document?
>

It is used to style the infoPanels. These are hidden.

For example:
http://www.netflix.com/Search?v1=boris

The Netflix page features a popup div (that code is definitely not to
be taken as a example of quality engineering). That page could
potentially take advantage of loading the "popup" div's css until
after the script that calls it had loaded and run.

Anything that is an enhancement of the original content, such as a
hidden "search suggest" div, "tooltip" divs, or content loaded via XHR
might want to load and apply external CSS later.

In this case, the initial page layout is not affected by the linked
stylesheet. Before the script executes, the deferred linked stylesheet
must be rendered.

A deferred a stylesheet would load after the page loads, but if a
script declared "depends=", the stylesheet resource would have to be
complete before the script would run.

Garrett

> -Boris
>
>


From bzbarsky at MIT.EDU  Mon Feb  9 19:37:11 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 09 Feb 2009 22:37:11 -0500
Subject: [whatwg] defer on style, depends
In-Reply-To: <c9e12660902091815q3a659cf6q592ab7844f7b179f@mail.gmail.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>	
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>	
	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>	
	<Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com>	
	<c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>	
	<49906AFA.804@mit.edu>	
	<c9e12660902091056t10eba8d1i91bcb8f9bda3a528@mail.gmail.com>	
	<49908A11.6070905@mit.edu>
	<c9e12660902091815q3a659cf6q592ab7844f7b179f@mail.gmail.com>
Message-ID: <4990F667.5060701@mit.edu>

Garrett Smith wrote:
> In general, I want better declarative control over loading external
> resources. The solution(s) should not cause compatibility problems
> with existing browsers (because I have to support IE6 and Firefox 2).

Honestly, by the time anything we're discussing now will be shipping in 
a browser Firefox 2 marketshare should be nonexistent.  I can't speak 
for IE6.

> I want the browser to be able to load and run a script without being
> in the position of trying to determine if it should wait for
> stylesheet data to complete.

As in you don't want the browser to make this determination, right? 
That is, you know that your script doesn't depend on any style data and 
you want the browser to just run it?

I would be fine with a way to flag scripts with that information, though 
there is a catch-22: if you flag such a script and it DOES depend on 
style information, then existing UAs will get it "right" and any UA 
implementing the new spec will get it "wrong".

Of course the same is true for the "flag-the-stylesheet" proposal...

> In browsers that do support defer, the script would run *after* the
> document parsed, and that would occur after the stylesheet loaded.

I'm not sure why this is a performance problem, per se.

>>> 2) want to load stylesheets later, (infoPanel example)
>> Not sure what this example is, or why this is insufficienty served by, say,
>> putting the <link> at the end of the HTML (assuming HTML allowed that, of
>> course).
> 
> Are you proposing HTML allow that?

That's one possible solution to the issue of starting stylesheet loads 
as late as possible, yes.  It's not a great one a priori, but has the 
benefit of good compat with existing UAs (which you said was a priority 
for you).

> The script could declare whether it needs such resource by its
> "depends=" attribute. However, browsers today delay (some) scripts
> from running. Scripts depend on stylesheets; content depends on
> scripts and stylesheets. Content can contain more scripts. Omitting
> depends for scripts could not possibly solve the problem for browsers
> today (because they already depend on stylesheets).

Honestly, I don't think anything would solve the problem for browsers 
_today_.

> An "independent" attribute on a link says that a browser does not need
> to wait for that resource to finish loading before it loads other
> resources (like loading a script). When the parser parses that
> "independent" attribute, it sets a flag for the browser go ahead and
> download and run any subsequent script.

That doesn't work for today's browsers, though, just like flagging the 
script doesn't.  Or am I missing something?

> A "nodepends" type attribute on a script would work, too. I like that
> idea, though it does mean the browser has to do some lookahead (then
> again, apparently they already do).

What sort of lookahead?  Gecko, for example, just keeps parsing right 
past a stylesheet load.  The only thing we stop the parser for is 
<script>s, because those can do document.write.  And even then, the 
speculative parser continues doing loads past that point.

All that style sheets hold up is the script running, not the script 
loading (in Gecko).  If the script were marked as "doesn't have to wait 
for stylesheets", we could just run it as soon as it loads.

>> That's exactly what Gecko does in this case, for what it's worth.  It will
>> load the script in parallel, but won't _execute_ the script until the
>> non-alternate stylesheet has loaded.
> 
> For a script in the head, that is what Gecko and Webkit will do.

What I said was true for all scripts.  We do not differentiate between 
content in <head> and content in <body> in this regard.

> However, external resources such as SCRIPT or IMG that appear in the
> BODY will not get requested by the browser until the page content
> renders.

You mean until all the HTML before the tag has been parsed?  Or 
something else?  There's no dependency between script loading+execution 
and page rendering, in Gecko.  Heck, you can run scripts in a 
display:none iframe, with no rendering in sight.

> In both cases (head script or body script), the browser will not
> execute the script until the stylesheet is downloaded. It won't render
> content that occurs after the script until the script is executed.

That's correct, yes.

> So what we have here is a daisy chain. Content depends on Script
> depends on Style. That is very crude order of affairs and offers the
> developer little control over load order.

Yes, agreed.

> to fulfill example 2, I would defer the stylesheet, and declare the
> script at the end depends on it. Before that script could run, the
> stylesheet would need to be loaded. Since the linked stylesheet is
> deferred, the body content would render and not be blocked by the
> linked stylesheet loading.

Ah, that is one thing that Gecko does do: we don't start _layout_ (as 
opposed to parsing) until all the stylesheets in <head> have loaded.

You can get around this trivially by putting a stylesheet as the first 
thing in <body>; that stylesheet won't block rendering in Gecko 1.9. 
You get a performance hit when the sheet loads, of course, because of 
the ensuing restyle, but you might be ok with that (I presume you are 
given that you want to load the stylesheet after the content has been 
rendered).

In fact, if you use a <script defer> after the sheet and a sheet at body 
start you'll get the behavior you want in Gecko 1.9.

Again, I doubt we can come up with any declarative solution that would 
work with UAs that don't implement defer already....

> Question: When the stylesheet is eventually applied, could the reflow
> be optimized for performance?

Not easily, no.  Or rather, the reflow already is; the style data 
recomputation is the hard part.

> A deferred a stylesheet would load after the page loads

Note that this is not the behavior deferred scripts have, by the way, at 
least in Gecko.  They load eagerly, but execute lazily...

-Boris


From ian at hixie.ch  Tue Feb 10 01:02:36 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Feb 2009 09:02:36 +0000 (UTC)
Subject: [whatwg] [html5] Semantic elements and spec complexity
In-Reply-To: <41924EDD.7000602@cam.ac.uk>
References: <412901B0.3070500@annevankesteren.nl>
	<Pine.LNX.4.61.0408281349300.8458@dhalsim.dreamhost.com>
	<4130B594.2000006@annevankesteren.nl>
	<Pine.LNX.4.61.0411091436280.4110@dhalsim.dreamhost.com>
	<689CD652-3320-11D9-8ACF-000A95AD3972@myrealbox.com>
	<41924EDD.7000602@cam.ac.uk>
Message-ID: <Pine.LNX.4.62.0902100625270.28232@hixie.dreamhostps.com>

On Thu, 11 Nov 2004, Matthew Thomas wrote:
> 
> I believe the past 15 years of semantic markup have shown these three 
> things to be true:
> 
> 1.  Most authors Just Don't Care about semantic markup. They'll only use
>     it if it's the easiest way of getting the visual effect or behavior
>     they want in their own favorite browser, or if they can use it to
>     game search engines. (That's why authors use <ul> and <li>, for
>     example, but not <address>.)

I don't know if the thrust of this argument is true, but I am pretty sure 
the parenthetical isn't. If authors don't use <address> I think it's 
because of a variety of reasons including its poor name, and its lack of 
particularly useful purpose.

I think there is a wide range of authoring styles, ranging from the author 
who really hasn't any idea that there is such a thing as semantics, and 
just thinks visually, to the author who just wants to get stuff done but 
understands that there are elements for specific purposes like lists, to 
the author who has bought the semantics religion but doesn't really 
understand it, leading to all kinds of "innovative" (and wrong) uses of 
HTML's less well known elements.


> 2.  Those authors who do care about semantic markup often do so
>     overzealously, using it even when it's not appropriate. For example,
>     they use <em> whenever they want italics or <strong> whenever they
>     want bold.

There are certainly authors who misuse semantic markup for reasons other 
than desiring presentational effects, yes.


> 3.  The more complex a markup language, the fewer people understand it,
>     the less conformant the average article will be, so the less useful
>     the Web's semantics will be. Current HTML authors may clamour for
>     new features, but they have forgotten what it was like to be a new
>     HTML author; and new authors are neither subscribed to this list nor
>     employed by browser vendors, so it is easy to forget about them.

Agreed.


> So if <section>, <navigation>, <header>, <footer>, <article>, and <sidebar>
> are introduced, with the default presentation currently suggested {display:
> block; margin: 0;}, I predict the following:
> 
> *   The A-list of Web developers will begin using all the elements
>     correctly on their Weblogs, and they will feel good about it.
> 
> *   A greater number of Web developers will never use most of these
>     elements, but they will replace all occurrences of <div> on their
>     pages with <section> because it's more "semantic" (just like they
>     did with <em> for <i> and <strong> for <b>), and they will feel good
>     about it.
> 
> *   The vast majority of article producers (Weblogs and online
>     newspapers) will never use <article>, because there's no visual or
>     behavioral benefit from doing so. So <article> will never become a
>     reliable way of dissecting or aggregating pages.
> 
> *   The number of knowledgable HTML authors, the proportion of HTML
>     pages that are valid, and therefore the overall usefulness of the
>     Web, will be less than it otherwise would have been because of
>     HTML's increased complexity.

I don't really think that such a dire consequence is likely.


> One way of improving this situation would be to reduce the number of new 
> elements -- forget about <article> and <footer>, for example.

These elements map pretty closely to common class values (in particular 
footer is the most common class name), so I don't think this is 
necessarily a good way to go.


> Another way would be to recommend more distinct default presentation for each
> of the elements -- for example, default <article> to having a drop cap,
> default <sidebar> to floating right, default <header>, <footer>, and
> <navigation> to having a slightly darker background than their parent element,
> and default <header>...<li> and <footer>...</li> to inline presentation. This
> would make authors more likely to choose the appropriate element.

I agree that this would be interesting. However, I'm at a loss as to what 
styles to use. Doing things like drop caps sounds cool, but in practice I 
fear it would actually discourage use due to weirdness and people not 
knowing how to override it (you'd have to do "article > p:first-line { 
font-variant: normal; }", which is pretty esoteric for the authors you 
mentioned just a little earlier).

Similarly, floating sounds like a good idea until you start considering 
how to make it interact with other text -- you'd need margins, and 
probably a top and bottom border, and padding, and a min-width, and a 
max-width... and soon you're at a level so complex that new authors are 
never going to be able figure it out, which defeats the whole point.


> A complementary long-term approach would be to deprecate the most 
> redundant and/or least effectual elements and attributes from HTML 4.01 
> -- for example, <acronym>, <big>, <small>, <q>, <var>, accesskey=, 
> cite=, longdesc=, and name= -- in preparation for removing them. This 
> would eventually help reduce the complexity of the spec.

Many of these, and many others, are indeed obsoleted in HTML5.


On Wed, 10 Nov 2004, James Graham wrote:
>
> This isn't really true, in general. For example, many sites fail to use 
> headings (and use odd combinations of <font> and <b> and <big> to get 
> the same effect) even though headings are the easiest way to get 
> something that looks kindof like a heading. In fact, unwanted styling on 
> elements has an adverse effect on their use (e.g. I have heard people 
> say "h1 shouldn't be used because the font is too big").

I'm not sure what to do about this, but it is an argument against 
providing complicated styles for the new elements.


> > So if <section>, <navigation>, <header>, <footer>, <article>, and 
> > <sidebar> are introduced, with the default presentation currently 
> > suggested {display: block; margin: 0;}, I predict the following:
> > 
> > *   A greater number of Web developers will never use most of these
> >     elements, but they will replace all occurrences of <div> on their
> >     pages with <section> because it's more "semantic" (just like they
> >     did with <em> for <i> and <strong> for <b>), and they will feel good
> >     about it. 
> 
> This could be a problem. In principle, the 'visual difference' should be 
> the link between <section> and headings. That might not be enough.

I'm not sure what else we can do.


> Did I already suggest an official authoring guide for the spec that 
> would explain the difference between <div> and <section> (and other such 
> issues) in a more approachable way than the spec itself can? If not, it 
> seems like a good idea.

Lachlan and DanC are now working on this, as I understand it.


> > , default <header>, <footer>, and <navigation> to having a slightly 
> > darker background than their parent element
> 
> It seems like there should be something more obvious that could be done 
> for these elements. For <header> and <footer> a border below and above, 
> respectivly, would seem obvious.

That would be simple enough, I guess; what do other people think?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From philipj at opera.com  Tue Feb 10 01:18:00 2009
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Tue, 10 Feb 2009 10:18:00 +0100
Subject: [whatwg] Video playback quality metric
In-Reply-To: <35c92870902091313u3c763a20sea0b322a1bf4afdd@mail.gmail.com>
References: <35c92870902091313u3c763a20sea0b322a1bf4afdd@mail.gmail.com>
Message-ID: <op.uo4pgawgatwj1d@spock.linkoping.osa>

On Mon, 09 Feb 2009 22:13:09 +0100, Jeremy Doig <jeremydo at google.com>  
wrote:

> Measuring the rate at which the playback buffer is filling/emptying  
> gives a
> fair indication of network goodput, but there does not appear to be a  
> way to
> measure just how well the client is playing the video itself. If I have a
> wimpy machine behind a fat network connection, you may flood me with HD  
> that
> I just can't play very well. The cpu or video card may just not be able  
> to
> render the video well.Exposing a metric (eg: Dropped Frame count,  
> rendered
> frame rate) would allow sites to dynamically adjust the video which is  
> being
> sent to a client [eg: switch the url to a differently encoded file] and
> thereby optimize the playback experience.
> Anyone else think this would be good to have ?

While I think this kind of thing might be useful, I would be careful about  
requiring any kind of detailed metrics like dropped frames or effective  
frame rate to be exposed via DOM, as getting this information reliably  
over different devices, platforms and media frameworks would be quite  
difficult. How about an event which the user agent can optionally fire to  
indicate that it cannot play at the requested rate due to  
processing/memory constraints (rather than network)? This would (I think)  
provide the same functionality but put less burden on implementors.

There is already a placeholder for non-fatal errors in the spec, perhaps  
this could be included with that in some fashion?

-- 
Philip J?genstedt
Opera Software


From ian at hixie.ch  Tue Feb 10 01:22:29 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Feb 2009 09:22:29 +0000 (UTC)
Subject: [whatwg] [web-apps] Ability to treat transparent part of
 element transparent to events
In-Reply-To: <41E3C447.1090105@hotpop.com>
References: <41E3C447.1090105@hotpop.com>
Message-ID: <Pine.LNX.4.62.0902100921370.28232@hixie.dreamhostps.com>

On Tue, 11 Jan 2005, martijnw wrote:
>
> See:
> https://bugzilla.mozilla.org/show_bug.cgi?id=102695 - Treat some transparent
> elements as "transparent to events"
> I think that explains basically what I would like to have.
> Afaik, that's something that IE is already doing (at least I heard).
> Basically, I was thinking about some sort of attribute that would enable this
> behavior.
> Is this something worth considering for the Web Applications spec?

Apparently the CSS group is considering applying the 'pointer-events' 
property to HTML content as well as SVG, so this is an issue for the 
www-style mailing list now.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From simonp at opera.com  Tue Feb 10 01:27:36 2009
From: simonp at opera.com (Simon Pieters)
Date: Tue, 10 Feb 2009 10:27:36 +0100
Subject: [whatwg] [html5] Semantic elements and spec complexity
In-Reply-To: <Pine.LNX.4.62.0902100625270.28232@hixie.dreamhostps.com>
References: <412901B0.3070500@annevankesteren.nl>
	<Pine.LNX.4.61.0408281349300.8458@dhalsim.dreamhost.com>
	<4130B594.2000006@annevankesteren.nl>
	<Pine.LNX.4.61.0411091436280.4110@dhalsim.dreamhost.com>
	<689CD652-3320-11D9-8ACF-000A95AD3972@myrealbox.com>
	<41924EDD.7000602@cam.ac.uk>
	<Pine.LNX.4.62.0902100625270.28232@hixie.dreamhostps.com>
Message-ID: <op.uo4pwahyidj3kv@hp-a0a83fcd39d2>

On Tue, 10 Feb 2009 10:02:36 +0100, Ian Hickson <ian at hixie.ch> wrote:

>> > , default <header>, <footer>, and <navigation> to having a slightly
>> > darker background than their parent element
>>
>> It seems like there should be something more obvious that could be done
>> for these elements. For <header> and <footer> a border below and above,
>> respectivly, would seem obvious.
>
> That would be simple enough, I guess; what do other people think?

I think many authors hate default styles so much that they either prefer to just use <div> or they start their style sheet with resetting the defaults.

Since <header> is intended to be useful to make subheaders not appear in the ToC, the move from

   <h1>Foo</h1>
   <h2>Bar</h2>

to

   <header>
    <h1>Foo</h1>
    <h2>Bar</h2>
   </header>

shouldn't, IMHO, result in ugly borders that everyone has to nuke (compare with <img border=0>).

-- 
Simon Pieters
Opera Software




From ian at hixie.ch  Tue Feb 10 01:29:10 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Feb 2009 09:29:10 +0000 (UTC)
Subject: [whatwg] [html5] Semantic elements and spec complexity
In-Reply-To: <op.uo4pwahyidj3kv@hp-a0a83fcd39d2>
References: <412901B0.3070500@annevankesteren.nl>
	<Pine.LNX.4.61.0408281349300.8458@dhalsim.dreamhost.com>
	<4130B594.2000006@annevankesteren.nl>
	<Pine.LNX.4.61.0411091436280.4110@dhalsim.dreamhost.com>
	<689CD652-3320-11D9-8ACF-000A95AD3972@myrealbox.com>
	<41924EDD.7000602@cam.ac.uk>
	<Pine.LNX.4.62.0902100625270.28232@hixie.dreamhostps.com>
	<op.uo4pwahyidj3kv@hp-a0a83fcd39d2>
Message-ID: <Pine.LNX.4.62.0902100928530.952@hixie.dreamhostps.com>

On Tue, 10 Feb 2009, Simon Pieters wrote:
> On Tue, 10 Feb 2009 10:02:36 +0100, Ian Hickson <ian at hixie.ch> wrote:
> > > > , default <header>, <footer>, and <navigation> to having a 
> > > > slightly darker background than their parent element
> > > 
> > > It seems like there should be something more obvious that could be 
> > > done for these elements. For <header> and <footer> a border below 
> > > and above, respectivly, would seem obvious.
> > 
> > That would be simple enough, I guess; what do other people think?
> 
> I think many authors hate default styles so much that they either prefer 
> to just use <div> or they start their style sheet with resetting the 
> defaults.
> 
> Since <header> is intended to be useful to make subheaders not appear in 
> the ToC, the move from
> 
>   <h1>Foo</h1>
>   <h2>Bar</h2>
> 
> to
> 
>   <header>
>    <h1>Foo</h1>
>    <h2>Bar</h2>
>   </header>
> 
> shouldn't, IMHO, result in ugly borders that everyone has to nuke 
> (compare with <img border=0>).

Yeah, that's a good point. I've left it at just display:block.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From jgraham at opera.com  Tue Feb 10 01:38:01 2009
From: jgraham at opera.com (James Graham)
Date: Tue, 10 Feb 2009 10:38:01 +0100
Subject: [whatwg] Video playback quality metric
In-Reply-To: <35c92870902091313u3c763a20sea0b322a1bf4afdd@mail.gmail.com>
References: <35c92870902091313u3c763a20sea0b322a1bf4afdd@mail.gmail.com>
Message-ID: <49914AF9.10804@opera.com>

Jeremy Doig wrote:
> Measuring the rate at which the playback buffer is filling/emptying gives a
> fair indication of network goodput, but there does not appear to be a way to
> measure just how well the client is playing the video itself. If I have a
> wimpy machine behind a fat network connection, you may flood me with HD that
> I just can't play very well. The cpu or video card may just not be able to
> render the video well.Exposing a metric (eg: Dropped Frame count, rendered
> frame rate) would allow sites to dynamically adjust the video which is being
> sent to a client [eg: switch the url to a differently encoded file] and
> thereby optimize the playback experience.
> Anyone else think this would be good to have ?

It seems like, in the short term at least, the "worse is better" 
solution to this problem is for content providers to provide links to 
resources at different quality levels, and allow users to choose the 
most appropriate resource based on their internet connection and their 
computer rather than having the computer try to work it out for them. 
Assuming that the majority of users use a relatively small number of 
sites with the resources to provide multiple-quality versions of their 
videos and use a small number of computing devices with roughly 
unchanging network conditions (I imagine this scenario applies to the 
majority of non-technical), they will quickly learn which versions of 
the media works best for them on each site. Therefore the burden of this 
simple approach on end users does not seem to be very high.

Given this, I would prefer automatic quality negotiation be deferred to 
  HTML6.


From jgraham at opera.com  Tue Feb 10 01:39:42 2009
From: jgraham at opera.com (James Graham)
Date: Tue, 10 Feb 2009 10:39:42 +0100
Subject: [whatwg] [html5] Semantic elements and spec complexity
In-Reply-To: <Pine.LNX.4.62.0902100928530.952@hixie.dreamhostps.com>
References: <412901B0.3070500@annevankesteren.nl>	<Pine.LNX.4.61.0408281349300.8458@dhalsim.dreamhost.com>	<4130B594.2000006@annevankesteren.nl>	<Pine.LNX.4.61.0411091436280.4110@dhalsim.dreamhost.com>	<689CD652-3320-11D9-8ACF-000A95AD3972@myrealbox.com>	<41924EDD.7000602@cam.ac.uk>	<Pine.LNX.4.62.0902100625270.28232@hixie.dreamhostps.com>	<op.uo4pwahyidj3kv@hp-a0a83fcd39d2>
	<Pine.LNX.4.62.0902100928530.952@hixie.dreamhostps.com>
Message-ID: <49914B5E.1010903@opera.com>


>> Since <header> is intended to be useful to make subheaders not appear in 
>> the ToC, the move from
>> 
>>   <h1>Foo</h1>
>>   <h2>Bar</h2>
>> 
>> to
>> 
>>   <header>
>>    <h1>Foo</h1>
>>    <h2>Bar</h2>
>>   </header>
>> shouldn't, IMHO, result in ugly borders that everyone has to nuke 
>> (compare with <img border=0>).
> 
> Yeah, that's a good point. I've left it at just display:block.
> 

Four-and-a-bit years on I tend to agree :)


From ian at hixie.ch  Tue Feb 10 01:42:23 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Feb 2009 09:42:23 +0000 (UTC)
Subject: [whatwg] MediaModeAbstractView and changing of media dynamically
In-Reply-To: <op.tf6cqlzvaw9dld@id-c0020.emi.ac.ma>
References: <op.tf5ffmvzxl3at9@dragast.mshome.net>
	<op.tf6cqlzvaw9dld@id-c0020.emi.ac.ma>
Message-ID: <Pine.LNX.4.62.0902100941000.28232@hixie.dreamhostps.com>

On Wed, 20 Sep 2006, Anne van Kesteren wrote:
> On Tue, 19 Sep 2006 23:27:12 -0000, Joao Eiras <joao.eiras at gmail.com> wrote:
> >
> > So, I suggest the creation of the 'media-change' event, which will 
> > fire when the UA changes media, having the document as target. The 
> > event object could be an instance of a UIEvent, and have 2 extra 
> > properties: newMediaMode, and oldMediaMode.
> 
> This has already been suggested multiple times on this list. Personally, 
> I think a better place is probably the new CSSOM (whenever I get around 
> to it...).

I agree that this would be better in CSSOM.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From shadow2531 at gmail.com  Tue Feb 10 01:54:18 2009
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Tue, 10 Feb 2009 04:54:18 -0500
Subject: [whatwg] Video playback quality metric
In-Reply-To: <49914AF9.10804@opera.com>
References: <35c92870902091313u3c763a20sea0b322a1bf4afdd@mail.gmail.com>
	<49914AF9.10804@opera.com>
Message-ID: <op.uo4q4rgr1ejg13@sandra-svwliu01>

On Tue, 10 Feb 2009 04:38:01 -0500, James Graham <jgraham at opera.com> wrote:

> Jeremy Doig wrote:
>> Measuring the rate at which the playback buffer is filling/emptying  
>> gives a
>> fair indication of network goodput, but there does not appear to be a  
>> way to
>> measure just how well the client is playing the video itself. If I have  
>> a
>> wimpy machine behind a fat network connection, you may flood me with HD  
>> that
>> I just can't play very well. The cpu or video card may just not be able  
>> to
>> render the video well.Exposing a metric (eg: Dropped Frame count,  
>> rendered
>> frame rate) would allow sites to dynamically adjust the video which is  
>> being
>> sent to a client [eg: switch the url to a differently encoded file] and
>> thereby optimize the playback experience.
>> Anyone else think this would be good to have ?
>
> It seems like, in the short term at least, the "worse is better"  
> solution to this problem is for content providers to provide links to  
> resources at different quality levels, and allow users to choose the  
> most appropriate resource based on their internet connection and their  
> computer rather than having the computer try to work it out for them.  
> Assuming that the majority of users use a relatively small number of  
> sites with the resources to provide multiple-quality versions of their  
> videos and use a small number of computing devices with roughly  
> unchanging network conditions (I imagine this scenario applies to the  
> majority of non-technical), they will quickly learn which versions of  
> the media works best for them on each site. Therefore the burden of this  
> simple approach on end users does not seem to be very high.
>
> Given this, I would prefer automatic quality negotiation be deferred to  
>   HTML6.

Flash has low, medium and high quality that the user can change (although a lot of sites/players seem to rudely disable that option in the menu for some reason). This helps out a lot and can allow a video to play better. I could imagine an "Auto" option too that automatically switched quality as necessary to get decent playback.

As an event, a site could use it like:

video.onplaybacktooslow = function() {
    this.quality = "low";
    this.setToNativeSize(); // stretched videos use more cpu
};

Or, something like that.

-- 
Michael




From ian at hixie.ch  Tue Feb 10 02:14:48 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Feb 2009 10:14:48 +0000 (UTC)
Subject: [whatwg] Hyphenation
In-Reply-To: <E1H5A4z-0006nc-00@ws7.ou-data.net>
References: <E1H5A4z-0006nc-00@ws7.ou-data.net>
Message-ID: <Pine.LNX.4.62.0902100943210.28232@hixie.dreamhostps.com>

On Tue, 9 Jan 2007, ?istein E. Andersen wrote:
>
> Hyphenation does not seem to have been discussed on this list so far, 
> and I think it should be.
> 
> Old proposal:
>     [2] http://www.nada.kth.se/i18n/html/hyph.html

While I appreciate the problems faced by Swedish, German, and othes, I 
don't think this is a big enough problem to deserve solutions more 
complicated than the soft hyphen at this time.

Given that Unicode provides soft hyphen semantics and CSS provides the 
rendering rules, I don't think there is anything much for HTML5 to say on 
the matter at this time.


This thread included many further e-mails discussing the subject. I agree 
with most of the points made. There did not seem to be a consensus that 
this is something that HTML5 should do anything about. If hyphenation 
dictionaries are to be used, it seems CSS would be the best place for 
them. I haven't done anything in HTML5 to handle them.

As usual, please let me know if there is something I missed.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From ian at hixie.ch  Tue Feb 10 02:15:38 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Feb 2009 10:15:38 +0000 (UTC)
Subject: [whatwg] Ideas regarding Web Applications 1.0
In-Reply-To: <DBA80908-E697-4D4D-A247-C93B76A38E0E@nickshanks.com>
References: <416F3BC8.9060600@earthlink.net>
	<Pine.LNX.4.61.0411222353110.18516@dhalsim.dreamhost.com>
	<41A346A5.3060403@earthlink.net>
	<Pine.LNX.4.62.0702280335360.7417@dhalsim.dreamhost.com>
	<DBA80908-E697-4D4D-A247-C93B76A38E0E@nickshanks.com>
Message-ID: <Pine.LNX.4.62.0902101015211.28232@hixie.dreamhostps.com>

On Mon, 12 Mar 2007, Nicholas Shanks wrote:
> On 28 Feb 2007, at 05:38, Ian Hickson wrote:
> 
> > For example, your page-wide header might need shortening on handheld 
> > media. I don't have a good proposal for this. Maybe we need the 
> > opposite of <abbr>?
> 
> We already have the opposite of the abbr element. It's called? the abbr 
> attribute (for th elements). And yes, it would be nice, though not 
> really essential, if there were a blessed mechanism for specifying 
> different titles for different display media. This can be achieved 
> through CSS media queries & CSS3's "content" property at present, and I 
> don't think the usage case is sufficient to warrant an extension of 
> HTML.

Agreed. I haven't added anything for this case.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From ian at hixie.ch  Tue Feb 10 02:19:39 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Feb 2009 10:19:39 +0000 (UTC)
Subject: [whatwg] How to improve the appearance of web pages
In-Reply-To: <45F6AA9C.4090303@opera.com>
References: <5d0394600703130626s1219680v9b939c1080b2c186@mail.gmail.com>
	<45F6A889.2020109@mozilla.org> <45F6AA9C.4090303@opera.com>
Message-ID: <Pine.LNX.4.62.0902101018040.28232@hixie.dreamhostps.com>

On Tue, 13 Mar 2007, Behnam ZWNJ Esfahbod wrote:
> 
> Implementing a new web application from scratch, I found out some new 
> ideas to make the appearance of site better.  I'm not sure here are the 
> best place for this discussion, but at least it's not out of interest.
> 
> First one is how Mozilla/Firefox do the zooming thing, "Text Size". On 
> web sites with images, changing the text size just works for +/- 2 
> levels.  More than that the whole page gets out of shape.  Seems Gecko 
> 1.9/Firefox 3 is going to resize images, but I'm not sure.
> 
> BTW the first trick is how to make images "zoomable", by the ratio of 
> "Text Size".  I set an style attribute for each image (which are not a 
> lot, limited to the logos) which sets "font-size" to image's width (in 
> pixel) and set the image's "width" to "1em".  It works well on Fx2.0 and 
> IE6.
> 
> The problem is there's no way to do it globaly, and I should add a 
> "style" attribute to each "img" tag.
> 
> Something I found weird is the default unit of images without width and 
> height attributes.  If there was a way to just set the default unit of 
> images to "em", the problem could be solved.

The problem is better solved using actual pixel zoom, rather than text 
zoom. Most browsers do this now.


> The second one is to get the web server decide which image file is 
> better.  An Apache httpd module can select the best response for a 
> request for image "the-company-logo" if it knows which size is needed, 
> and what mime-types are acceptable.
> 
> My idea is to add a field to the http request header for image files, to 
> let the server know which size the image is going to be shown, and then 
> it decides to send the best answer. [...]
> 
> Another usage is when the browser does the zooming.  When I zoom in the 
> page 200%, that's good if browser can get the company logo with better 
> quality.  It would be just another request for "the-company-logo" with 
> the 384 pixels width, and it may be a bitmap or vector file again. [...]

I recommend bringing this up with the HTTP working group, as it seems out 
of scope for HTML5.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Feb 10 02:52:32 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Feb 2009 10:52:32 +0000 (UTC)
Subject: [whatwg] Default (informal) Style Sheet
In-Reply-To: <p06240604c23b469a82e6@[192.168.0.101]>
References: <op.tp2z5ont5rel5w@quark> <p06240625c2359413f367@[192.168.0.101]>
	<461082E9.3040406@mikeschinkel.com>
	<p0624062cc2365f319cc2@[192.168.0.101]>
	<4610AE2B.8010203@mikeschinkel.com>
	<p06240604c23b469a82e6@[192.168.0.101]>
Message-ID: <Pine.LNX.4.62.0902101040270.28232@hixie.dreamhostps.com>

On Sun, 1 Apr 2007, Kempen, E.J.F. van wrote:
> >
> > [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Asbj?rn Ulsberg
> >
> > While HTML is a semantic markup language, it's not something to ignore 
> > that it's mostly used for visual rendering of content, often 
> > accompanied by a CSS document. While I'm a strong believer of 
> > separation between structure (HTML), presentation (CSS) and 
> > functionality (JavaScript), I think it could be useful for the HTML 
> > specification to -- within limits -- define how each and every 
> > element's default CSS properties and values should be like.
> 
> I totally agree with you at the point of the importance of layer 
> separation, but I'm not sure about specifying the default CSS values. 
> There are a few options:
> 
> * let the CSS be built from scratch *
> No styles are defined, so by default the CSS values are empty. I don't 
> think this a good option, because people won't define their styles from 
> scratch, resulting in vendors still needing to define default styles. So 
> that's no solution.
> 
> * Vendors keep defining the default values for every element *
> If a web developer disagrees with the vendors, he will just define it in 
> his CSS.
> 
> * the HTML WG defines default values for every element *
> This can be a solution for HTML as web representation. Defining defaults 
> can result in vendors implementing the same defaults, so it looks the 
> same in every browser by default. I think it's good to think about these 
> things, but I wonder if it would change anything.
> 
> What exactly are you looking for? Defining that 'normal' text is black 
> by default and links are blue-ish? Because that's done already, most 
> default styles are uniformly, but maybe informally, defined. As the new 
> HTML spec is gradually being developed, a new document could be written 
> about default styles, but I don't think this should be in the new HTML 
> spec. I personally think such a complementary document, about the 
> default styles, is a good idea. These issues should certainly be 
> addressed in cooperation with the CSS WG.

The rendering section now does a mixture of the above.


On Sun, 1 Apr 2007, Martin Atkins wrote:
> 
> One example that springs to mind is that the default CSS rules for 
> unordered and ordered lists differ between browsers. Some implement the 
> bullets with padding and list-style, while others use margins and 
> god-knows-what. I can't really remember anymore. I've just learned that 
> the way to get rid of the bullets across all popular browsers is:
> 
> ul, ul li {
> margin: 0;
> padding: 0;
> list-style: none;
> }
> 
> If you don't set both margin and padding, you'll see inconsistent 
> results.

The spec now picks one.


On Mon, 2 Apr 2007, Asbj?rn Ulsberg wrote:
> 
> With CSS2.1, how would you style the button you get from an <input 
> type="file"> for instance?

<input type=file> is a special case, due to the security aspects.

In general, though, XBL is the only way to get to the bits of a widget, 
and that isn't implemented yet.


> > I personally think such a complementary document, about the default 
> > styles, is a good idea. These issues should certainly be addressed in 
> > cooperation with the CSS WG.
> > 
> > Any other thoughts?
> 
> If the HTML spec is going to contain informal fragments of Relax-NG, I 
> believe there's a place for informal fragments of CSS as well.

It isn't going to have the former. :-) The latter aren't really informal, 
they're a kind of half-way-required level.


On Sun, 1 Apr 2007, Sander Tekelenburg wrote:
> >
> > http://www.whatwg.org/specs/web-apps/current-work/#rendering
> 
> That saying "when scrolling a page to a fragment identifier, align the 
> top of the viewport with the target element's top border edge", seems to 
> emphasize my argument. This is a silly requirement.

This is now gone.


On Mon, 2 Apr 2007, Asbj?rn Ulsberg wrote:
> 
> Speaking of <hr>, having a default style for it would increase 
> interoperability (if only in the presentation layer) a great deal. 

Done.


This thread discussed a number of philosophical topics and it wasn't clear 
what a lot of it translated to, in terms of practical changes to the spec. 
I didn't reply to those bits. Please let me know if I missed some 
important feedback that should affect the spec.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From derernst at gmx.ch  Tue Feb 10 03:42:20 2009
From: derernst at gmx.ch (Markus Ernst)
Date: Tue, 10 Feb 2009 12:42:20 +0100
Subject: [whatwg] Hyphenation
In-Reply-To: <Pine.LNX.4.62.0902100943210.28232@hixie.dreamhostps.com>
References: <E1H5A4z-0006nc-00@ws7.ou-data.net>
	<Pine.LNX.4.62.0902100943210.28232@hixie.dreamhostps.com>
Message-ID: <4991681C.5090003@gmx.ch>

Ian Hickson schrieb:
> On Tue, 9 Jan 2007, ?istein E. Andersen wrote:
>> Hyphenation does not seem to have been discussed on this list so far, 
>> and I think it should be.
>>
>> Old proposal:
>>     [2] http://www.nada.kth.se/i18n/html/hyph.html
> 
> While I appreciate the problems faced by Swedish, German, and othes, I 
> don't think this is a big enough problem to deserve solutions more 
> complicated than the soft hyphen at this time.

Jukka Korpela stated that the intention of the soft hyphen is not 
actually a hyphenation hint:
http://www.cs.tut.fi/~jkorpela/shy.html

(Anyway I don't really understand the difference between a normal hyphen 
and a soft hyphen then...)

> Given that Unicode provides soft hyphen semantics and CSS provides the 
> rendering rules, I don't think there is anything much for HTML5 to say on 
> the matter at this time.
> 
> 
> This thread included many further e-mails discussing the subject. I agree 
> with most of the points made. There did not seem to be a consensus that 
> this is something that HTML5 should do anything about. If hyphenation 
> dictionaries are to be used, it seems CSS would be the best place for 
> them. I haven't done anything in HTML5 to handle them.

The wish for an in-text hyphenation mechanism is of course motivated by 
the habit of how we do it in office and layout softwares, where text and 
presentation are not separated. I totally agree that the appropriate 
place for it is presentation, thus CSS, and the CSS3 draft looks quite 
reasonable:
http://www.w3.org/TR/2007/WD-css3-gcpm-20070205/#hyphenation

Anyway I don't find anything about the format of the hyphenation 
dictionary. To replace in-text hyphenation hints it is necessary to have 
several levels of hyphenation quality - the german word for "hyphenation 
mechanism" for example, "Trennungsmechanismus", you might want to have 
hyphentated at any possible place inside body text, but only at 
"Trennungs-mechanismus" in a headline. I see that this list is not the 
appropriate place for suggestions about CSS3 properties - maybe someone 
can point me to the appropriate place?


From ian at hixie.ch  Tue Feb 10 04:03:38 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 10 Feb 2009 12:03:38 +0000 (UTC)
Subject: [whatwg] Hyphenation
In-Reply-To: <4991681C.5090003@gmx.ch>
References: <E1H5A4z-0006nc-00@ws7.ou-data.net>
	<Pine.LNX.4.62.0902100943210.28232@hixie.dreamhostps.com>
	<4991681C.5090003@gmx.ch>
Message-ID: <Pine.LNX.4.62.0902101201560.952@hixie.dreamhostps.com>

On Tue, 10 Feb 2009, Markus Ernst wrote:
> > 
> > While I appreciate the problems faced by Swedish, German, and othes, I 
> > don't think this is a big enough problem to deserve solutions more 
> > complicated than the soft hyphen at this time.
> 
> Jukka Korpela stated that the intention of the soft hyphen is not 
> actually a hyphenation hint: http://www.cs.tut.fi/~jkorpela/shy.html

As far as I can tell this is a non-issue; HTML5 defers to Unicode for the 
semantics of its characters, and Unicode is clear here. HTML5 doesn't 
support ISO 8859-1 (it always treats content labeled as such as a Win1252 
mapping to Unicode).


> The wish for an in-text hyphenation mechanism is of course motivated by 
> the habit of how we do it in office and layout softwares, where text and 
> presentation are not separated. I totally agree that the appropriate 
> place for it is presentation, thus CSS, and the CSS3 draft looks quite 
> reasonable: http://www.w3.org/TR/2007/WD-css3-gcpm-20070205/#hyphenation
> 
> Anyway I don't find anything about the format of the hyphenation 
> dictionary. To replace in-text hyphenation hints it is necessary to have 
> several levels of hyphenation quality - the german word for "hyphenation 
> mechanism" for example, "Trennungsmechanismus", you might want to have 
> hyphentated at any possible place inside body text, but only at 
> "Trennungs-mechanismus" in a headline. I see that this list is not the 
> appropriate place for suggestions about CSS3 properties - maybe someone 
> can point me to the appropriate place?

www-style at w3.org is the appropriate place. See the "Status of this 
document" section of the draft you cite above.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From Smylers at stripey.com  Tue Feb 10 05:40:12 2009
From: Smylers at stripey.com (Smylers)
Date: Tue, 10 Feb 2009 13:40:12 +0000
Subject: [whatwg] Hyphenation
In-Reply-To: <4991681C.5090003@gmx.ch>
References: <E1H5A4z-0006nc-00@ws7.ou-data.net>
	<Pine.LNX.4.62.0902100943210.28232@hixie.dreamhostps.com>
	<4991681C.5090003@gmx.ch>
Message-ID: <20090210134012.GA28731@stripey.com>

Markus Ernst writes:

> Ian Hickson schrieb:
> 
> > I don't think this is a big enough problem to deserve solutions more
> > complicated than the soft hyphen at this time.
> 
> Jukka Korpela stated that the intention of the soft hyphen is not 
> actually a hyphenation hint:
> http://www.cs.tut.fi/~jkorpela/shy.html

He claims that there are multiple standards that contradict each other.
So whatever is implemented is bound to contravene at least one of them.

However he mentions that:

* HTML 4 defines it as a hyphenation hint.

* Unicode defines it as a hyphenation hint.

* Recent browsers are now treating it as a hyphenation hint.

* The contradictory standard (ISO-8859) only defines a soft hyphen when
  used at the end of a line, namely that it should be rendered like a
  hyphen.  Since that standard doesn't envisage the character being used
  elsewhere, it is silent on how it should be rendered.

It seems to me that choosing to render invisibly a soft hyphen which
isn't at the end of a line doesn't contradict the text of ISO-8859
(though it could be argued to contradict its spirit).

> (Anyway I don't really understand the difference between a normal
> hyphen and a soft hyphen then...)

Suppose you are reflowing some text (perhaps because you are quoting
it); words which were broken over lines in the original may want
rejoining into a single word in your version (that is, the soft hyphen
disappears); but hyphens (non-soft) between two words need to remain.  

Smylers


From Smylers at stripey.com  Tue Feb 10 05:40:12 2009
From: Smylers at stripey.com (Smylers)
Date: Tue, 10 Feb 2009 13:40:12 +0000
Subject: [whatwg] Hyphenation
In-Reply-To: <4991681C.5090003@gmx.ch>
References: <E1H5A4z-0006nc-00@ws7.ou-data.net>
	<Pine.LNX.4.62.0902100943210.28232@hixie.dreamhostps.com>
	<4991681C.5090003@gmx.ch>
Message-ID: <20090210134012.GA28731@stripey.com>

Markus Ernst writes:

> Ian Hickson schrieb:
> 
> > I don't think this is a big enough problem to deserve solutions more
> > complicated than the soft hyphen at this time.
> 
> Jukka Korpela stated that the intention of the soft hyphen is not 
> actually a hyphenation hint:
> http://www.cs.tut.fi/~jkorpela/shy.html

He claims that there are multiple standards that contradict each other.
So whatever is implemented is bound to contravene at least one of them.

However he mentions that:

* HTML 4 defines it as a hyphenation hint.

* Unicode defines it as a hyphenation hint.

* Recent browsers are now treating it as a hyphenation hint.

* The contradictory standard (ISO-8859) only defines a soft hyphen when
  used at the end of a line, namely that it should be rendered like a
  hyphen.  Since that standard doesn't envisage the character being used
  elsewhere, it is silent on how it should be rendered.

It seems to me that choosing to render invisibly a soft hyphen which
isn't at the end of a line doesn't contradict the text of ISO-8859
(though it could be argued to contradict its spirit).

> (Anyway I don't really understand the difference between a normal
> hyphen and a soft hyphen then...)

Suppose you are reflowing some text (perhaps because you are quoting
it); words which were broken over lines in the original may want
rejoining into a single word in your version (that is, the soft hyphen
disappears); but hyphens (non-soft) between two words need to remain.  

Smylers


From list at asbjorn.ulsberg.no  Tue Feb 10 08:13:25 2009
From: list at asbjorn.ulsberg.no (=?iso-8859-15?Q?Asbj=F8rn_Ulsberg?=)
Date: Tue, 10 Feb 2009 17:13:25 +0100
Subject: [whatwg] Default (informal) Style Sheet
In-Reply-To: <Pine.LNX.4.62.0902101040270.28232@hixie.dreamhostps.com>
References: <op.tp2z5ont5rel5w@quark> <p06240625c2359413f367@[192.168.0.101]>
	<461082E9.3040406@mikeschinkel.com>
	<p0624062cc2365f319cc2@[192.168.0.101]>
	<4610AE2B.8010203@mikeschinkel.com>
	<p06240604c23b469a82e6@[192.168.0.101]>
	<Pine.LNX.4.62.0902101040270.28232@hixie.dreamhostps.com>
Message-ID: <op.uo48o1r2flu5h5@quark-mac-pro.local>

On Tue, 10 Feb 2009 11:52:32 +0100, Ian Hickson <ian at hixie.ch> wrote:

>> Speaking of <hr>, having a default style for it would increase
>> interoperability (if only in the presentation layer) a great deal.
>
> Done.

Excellent!

-- 
Asbj?rn Ulsberg         -=|=-          asbjorn at ulsberg.no
?He's a loathsome offensive brute, yet I can't look away?



From giles at xiph.org  Tue Feb 10 09:02:24 2009
From: giles at xiph.org (Ralph Giles)
Date: Tue, 10 Feb 2009 09:02:24 -0800
Subject: [whatwg] Video playback quality metric
In-Reply-To: <op.uo4q4rgr1ejg13@sandra-svwliu01>
References: <35c92870902091313u3c763a20sea0b322a1bf4afdd@mail.gmail.com>
	<49914AF9.10804@opera.com> <op.uo4q4rgr1ejg13@sandra-svwliu01>
Message-ID: <5d88ef650902100902k901cf4eyfd89fd8d82249438@mail.gmail.com>

On Tue, Feb 10, 2009 at 1:54 AM, Michael A. Puls II
<shadow2531 at gmail.com> wrote:

> Flash has low, medium and high quality that the user can change (although a
> lot of sites/players seem to rudely disable that option in the menu for some
> reason). This helps out a lot and can allow a video to play better. I could
> imagine an "Auto" option too that automatically switched quality as
> necessary to get decent playback.

Isn't that rendering quality? That can of course be adjusted by the
browser, dynamically and/or according to a user setting, with or
without a javascript interface.

 -r


From ian at hixie.ch  Tue Feb 10 16:22:59 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 00:22:59 +0000 (UTC)
Subject: [whatwg] Color attributes
In-Reply-To: <op.ui38bralidj3kv@zcorpandell.linkoping.osa>
References: <op.tu0hbhll7a8kvn@hp-a0a83fcd39d2>
	<op.ui38bralidj3kv@zcorpandell.linkoping.osa>
Message-ID: <Pine.LNX.4.62.0902110022310.28232@hixie.dreamhostps.com>

On Thu, 16 Oct 2008, Simon Pieters wrote:
>
> Color attributes in HTML have special processing. [...]
> 
> It seems that some pages use three-digit notation and expect it to work 
> as in CSS. I've made the algorithm do that and I've drafted up a spec 
> for this:
> 
>    http://simon.html5.org/specs/html-color-attributes

The spec now defines this.

Thanks for your work on this. It was hugely helpful.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Feb 10 17:15:19 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 01:15:19 +0000 (UTC)
Subject: [whatwg] Load SVG via IMG element
In-Reply-To: <3bceeb2d0710042228g7302e963q70f668e1627aaccf@mail.gmail.com>
References: <qimvn1ilwx4cvqm.041020072133@pinscher>
	<3bceeb2d0710042228g7302e963q70f668e1627aaccf@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902110114460.28232@hixie.dreamhostps.com>

On Thu, 4 Oct 2007, Vlad Alexander (xhtml.com) wrote:
>
> I noticed that Opera 9.5 can load an SVG image via the IMG element. I 
> think this is a wonderful thing. Is there any specification on how this 
> should work? For example, I noticed that Opera, for some reason, does 
> not scale SVG images to fit the box created by the IMG element's width 
> and height attributes. Here is a test page:
> 
> http://xhtml.com/misc/svg-img.htm
> 
> Can someone please point me to any specs on loading SVG via IMG element?

On Fri, 5 Oct 2007, Devi Web Development wrote:
>
> My understanding is that SVG should not be scaled to fit given 
> dimensions because scaling information is provided in the SVG itself. I 
> don't know about the full status of SVG in browsers, but I know that 
> Firefox supports some, and the Adobe plug-in is common. A full test 
> suite is available at http://www.w3.org/Graphics/SVG/Test/ A 
> specification for embedding SVG in XHTML can be found at 
> http://www.w3.org/TR/XHTMLplusMathMLplusSVG/ and Mozilla provides some 
> documentation at 
> http://developer.mozilla.org/en/docs/SVG_In_HTML_Introduction

It's not clear to me what I should say in HTML5 about this. <img> should 
just do whatever the image format says it should do, right?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Feb 10 17:31:33 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 01:31:33 +0000 (UTC)
Subject: [whatwg] [HTML5] Accessibility question
In-Reply-To: <370751.34777.qm@web57712.mail.re3.yahoo.com>
References: <370751.34777.qm@web57712.mail.re3.yahoo.com>
Message-ID: <Pine.LNX.4.62.0902110130480.28232@hixie.dreamhostps.com>

On Sat, 22 Mar 2008, Nicholas C. Zakas wrote:
>
> Apologies for not replying sooner, I've been struck with a bit of the 
> flu.
> 
> The problem I'm trying to solve is the case where you need descriptive 
> text for screen readers but that text is not necessary for sighted 
> users. For example, our accessibility guidelines at Yahoo! say that 
> every unordered list (<ul>) should be preceeded by a header that 
> describes its use. The header may say something like "Page options" or 
> "Available styles" and we use CSS tricks (text-indent: -10000px;) to 
> hide these headings from display while allowing screen readers to read 
> them. To sighted users, the meaning of the list is apparent because they 
> can see the visual treatments we've applied whereas blind users would 
> just hear a list read out of context.
> 
> Another example is for buttons that make use of sprites. Something is 
> implemented as a link but with a background image that's part of a 
> sprite. The link needs to have descriptive text for screen readers but 
> the text is unnecessary for sighted users as they can see the image. For 
> example:
> 
> <a href="#" class="close"><span>Close</span></a>
> 
> For things like this, I usually end up using the same CSS trick 
> mentioned above to move the "Close" text out of the way. Just looking at 
> the HTML, it's not apparent that "Close" is not intended to seen. 
> Whereas the following clears it up:
> 
> <a href="#" class="close"><span noview>Close</span></a>
> 
> Now I know from looking at the source code that "Close" is clearly not 
> intended to be seen.

This seems like a CSS problem. The text is only inapplicable because of 
the CSS, right? If the CSS wasn't applied, then even on a screen, the user 
would need the titles or button text you've described.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Feb 10 17:33:31 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 01:33:31 +0000 (UTC)
Subject: [whatwg] Warnings for non-applicable properties
In-Reply-To: <423830b0811092253l701ab43o8d3513e791149ae6@mail.gmail.com>
References: <423830b0811090311i4fd12019j44c888a73ac68f27@mail.gmail.com>
	<4916CA07.2010008@googlemail.com>
	<575E98E041AC455F8E133EA9BEDFAB67@JukanPC>
	<423830b0811092253l701ab43o8d3513e791149ae6@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902110132390.28232@hixie.dreamhostps.com>

On Mon, 10 Nov 2008, Paul Arzul wrote:
> 
> is it unfortunate that the html4 stylesheet is only informative? perhaps 
> html5 could then consider giving us a normative default user agent 
> stylesheet - or at least a normative version with only display 
> properties.

The spec has a semi-normative one now. User agents aren't required to 
follow it, because we never know when they might apply styles for 
particular users with special needs.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Feb 10 17:35:35 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 01:35:35 +0000 (UTC)
Subject: [whatwg] input type=image width/height attributes
In-Reply-To: <20081223204339.C5D493BA31@looneymail-mx1.g.dreamhost.com>
References: <20081223204339.C5D493BA31@looneymail-mx1.g.dreamhost.com>
Message-ID: <Pine.LNX.4.62.0902110135210.28232@hixie.dreamhostps.com>

On Tue, 23 Dec 2008, Kartikaya Gupta wrote:
>
> Are there any plans to add the width/height attributes for the input 
> element to the HTML5 spec? It seems that all browsers (Opera, FF, 
> Safari, IE) support width/height on <input type="image" in both quirks 
> and standards mode. There are websites that depend on this behavior (the 
> select-your-postal-code landing page at canadiantire.ca is one example) 
> and it doesn't seem to be specced anywhere that I could find.

They're specified now.

Thanks,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From mart at degeneration.co.uk  Tue Feb 10 17:54:14 2009
From: mart at degeneration.co.uk (Martin Atkins)
Date: Tue, 10 Feb 2009 17:54:14 -0800
Subject: [whatwg] Warnings for non-applicable properties
In-Reply-To: <Pine.LNX.4.62.0902110132390.28232@hixie.dreamhostps.com>
References: <423830b0811090311i4fd12019j44c888a73ac68f27@mail.gmail.com>	<4916CA07.2010008@googlemail.com>	<575E98E041AC455F8E133EA9BEDFAB67@JukanPC>	<423830b0811092253l701ab43o8d3513e791149ae6@mail.gmail.com>
	<Pine.LNX.4.62.0902110132390.28232@hixie.dreamhostps.com>
Message-ID: <49922FC6.4070901@degeneration.co.uk>

Ian Hickson wrote:
> On Mon, 10 Nov 2008, Paul Arzul wrote:
>> is it unfortunate that the html4 stylesheet is only informative? perhaps 
>> html5 could then consider giving us a normative default user agent 
>> stylesheet - or at least a normative version with only display 
>> properties.
> 
> The spec has a semi-normative one now. User agents aren't required to 
> follow it, because we never know when they might apply styles for 
> particular users with special needs.
> 

Could that arguably be considered to be a machine-generated user stylesheet?

I tend to think of the settings my browser has for choosing default 
fonts and so forth to be functionally equivalent to me writing a user 
stylesheet that contains the same settings.

This would allow the HTML spec to normatively require browsers to use a 
particular default stylesheet (or, indeed, act as if they've done so) 
while still allowing for user-specific alterations of various kinds.

(I believe that Mozilla is already implemented as above, more or less.)



From ddailey at zoominternet.net  Tue Feb 10 18:19:41 2009
From: ddailey at zoominternet.net (ddailey)
Date: Tue, 10 Feb 2009 21:19:41 -0500
Subject: [whatwg] Load SVG via IMG element
References: <qimvn1ilwx4cvqm.041020072133@pinscher><3bceeb2d0710042228g7302e963q70f668e1627aaccf@mail.gmail.com>
	<Pine.LNX.4.62.0902110114460.28232@hixie.dreamhostps.com>
Message-ID: <445745FE2DF348FAABDD2CE160AF06C4@disxgdg31szkx7>

In the message below, Ian Hickson wrote:
> It's not clear to me what I should say in HTML5 about this. <img> should
> just do whatever the image format says it should do, right?

I would think so, but I cc-ed Doug Schepers on this who might know of a 
reason not to.
I seem to recall some discussion of this somewhere, but if you didn't find 
it, Ian, then I doubt that I could.

David

btw, though off-topic here, the question from Vlad about browser support can 
be answered from Jeff Schiller's up-to-date info on implementations of the 
SVG spec at http://www.codedread.com/svg-support.php . In brief, all major 
browsers are implementing quite a bit of SVG natively now except for IE 
which still relies on a third party plugin. Opera does almost all of SVG1.1 
and WebKit is quite far along with SMIL (SVG animation).


----- Original Message ----- 
From: "Ian Hickson" <ian at hixie.ch>
To: "Vlad Alexander (xhtml.com)" <vlad.alexander at xhtml.com>; "Devi Web 
Development" <devi.webmaster at gmail.com>
Cc: <whatwg at whatwg.org>
Sent: Tuesday, February 10, 2009 8:15 PM
Subject: Re: [whatwg] Load SVG via IMG element


> On Thu, 4 Oct 2007, Vlad Alexander (xhtml.com) wrote:
>>
>> I noticed that Opera 9.5 can load an SVG image via the IMG element. I
>> think this is a wonderful thing. Is there any specification on how this
>> should work? For example, I noticed that Opera, for some reason, does
>> not scale SVG images to fit the box created by the IMG element's width
>> and height attributes. Here is a test page:
>>
>> http://xhtml.com/misc/svg-img.htm
>>
>> Can someone please point me to any specs on loading SVG via IMG element?
>
> On Fri, 5 Oct 2007, Devi Web Development wrote:
>>
>> My understanding is that SVG should not be scaled to fit given
>> dimensions because scaling information is provided in the SVG itself. I
>> don't know about the full status of SVG in browsers, but I know that
>> Firefox supports some, and the Adobe plug-in is common. A full test
>> suite is available at http://www.w3.org/Graphics/SVG/Test/ A
>> specification for embedding SVG in XHTML can be found at
>> http://www.w3.org/TR/XHTMLplusMathMLplusSVG/ and Mozilla provides some
>> documentation at
>> http://developer.mozilla.org/en/docs/SVG_In_HTML_Introduction
>
> It's not clear to me what I should say in HTML5 about this. <img> should
> just do whatever the image format says it should do, right?
>
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
> 



From ian at hixie.ch  Tue Feb 10 18:37:41 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 02:37:41 +0000 (UTC)
Subject: [whatwg] Warnings for non-applicable properties
In-Reply-To: <49922FC6.4070901@degeneration.co.uk>
References: <423830b0811090311i4fd12019j44c888a73ac68f27@mail.gmail.com>
	<4916CA07.2010008@googlemail.com>
	<575E98E041AC455F8E133EA9BEDFAB67@JukanPC>
	<423830b0811092253l701ab43o8d3513e791149ae6@mail.gmail.com>
	<Pine.LNX.4.62.0902110132390.28232@hixie.dreamhostps.com>
	<49922FC6.4070901@degeneration.co.uk>
Message-ID: <Pine.LNX.4.62.0902110236410.952@hixie.dreamhostps.com>

On Tue, 10 Feb 2009, Martin Atkins wrote:
> Ian Hickson wrote:
> > On Mon, 10 Nov 2008, Paul Arzul wrote:
> > > is it unfortunate that the html4 stylesheet is only informative? perhaps
> > > html5 could then consider giving us a normative default user agent
> > > stylesheet - or at least a normative version with only display properties.
> > 
> > The spec has a semi-normative one now. User agents aren't required to follow
> > it, because we never know when they might apply styles for particular users
> > with special needs.
> 
> Could that arguably be considered to be a machine-generated user 
> stylesheet?

Does it make any difference? The net result is that the user and the 
author can't rely on a single style sheet. What benefit would a definite 
UA style sheet be, if not that?


> This would allow the HTML spec to normatively require browsers to use a 
> particular default stylesheet (or, indeed, act as if they've done so) 
> while still allowing for user-specific alterations of various kinds.

There wouldn't be much point to that requirement, since it couldn't be 
usefully tested.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From jonas at sicking.cc  Tue Feb 10 19:04:22 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 10 Feb 2009 19:04:22 -0800
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <20090114005310.GG30640@arc.mcc.id.au>
References: <op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
	<Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
	<63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
	<20090113233707.GE30640@arc.mcc.id.au>
	<63df84f0901131610u75b81d2arbe245b7cbb44fd2a@mail.gmail.com>
	<20090114002642.GF30640@arc.mcc.id.au>
	<63df84f0901131642k7c26688eh13dd8182fb03743e@mail.gmail.com>
	<20090114005310.GG30640@arc.mcc.id.au>
Message-ID: <63df84f0902101904x7a164081wd71dd3ce779c1221@mail.gmail.com>

On Tue, Jan 13, 2009 at 4:53 PM, Cameron McCormack <cam at mcc.id.au> wrote:
> Jonas Sicking:
>> So it behaves different from passing in an empty string? For some
>> functions this surprises me, such as for the namespace parameter for
>> getAttributeNS, I would think that we there treat "" the same as null.
>
> Not necessarily, but I agree that would be a better thing to report.
> I'll rejig the tests to get that information.
>
> Cameron McCormack:
>> > OK.  So what is more important for choosing the default: fewer
>> > exceptions (and thus fewer [Null=?] things polluting the IDL),
>> > consistency with the default stringification behaviour of ECMAScript,
>> > or avoiding the somewhat counterintuitive default behaviour of
>> > converting a valid value of the type to a different value of that type?
>
>> "converting a valid value of the type to a different value of that
>> type", which values exactly?
>
> null.  It feels slightly strange to me to treat null as a "second class
> value" by default.  But I'll get over it. :-)

The point would be to not do it by default. I.e. default behavior is
to treat null as a valid value that is left untouched by default. And
only convert it to n-u-l-l when specified in IDL.

To answer your original question. I think the most important thing is
to have few exceptions that authors have to learn.

> It may actually be indicative of a need for two distinct types: strings
> (i.e., possibly empty sequences of characters) and strings-or-null.  But
> I don't know if it's worth rewriting everything in this way.

Yeah

/ Jonas


From ian at hixie.ch  Tue Feb 10 19:30:03 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 03:30:03 +0000 (UTC)
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>
References: <Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<498DD687.7060303@googlemail.com>
	<65307430902071051x639a5624j79284323e46f80ff@mail.gmail.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
	<498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
	<20090209142419.GA2461@stripey.com>
	<65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>

On Sat, 7 Feb 2009, Giovanni Campagna wrote:
> 2009/2/6 Ian Hickson <ian at hixie.ch>
> > On Fri, 6 Feb 2009, Giovanni Campagna wrote:
> > >
> > > I'm proposing to replace the current rendering mechanism, based on 
> > > Behavioural Extension to CSS, that in turn is based on XBL2, with 
> > > something based on the CSS3 Basic User Interface (css3-ui), ie 
> > > replacing the binding: property with appropriate appearance: 
> > > property directly on the element, instead of relying on the binding 
> > > itself.
> >
> > The two properties are orthogonal -- 'binding' sets the behavior, 
> > 'appearance' sets the look-and-feel.

> I thought about it later, and I realized that you cannot style complex 
> widgets without XBL (or something like that) because pseudo-elements are 
> not reached by events. If they ever would, we would have horrible 
> situations we have now.
>
> So for complex widgets (Number, File, Slider) it may be impossible to 
> avoid a binding property, but anywhere it is possible you should try to 
> use the available (appearance, content, icon, etc.). Even when using 
> those, the author is able to shut them down, and knows perfectly which 
> of them apply (they're defined normatively in HTML5 and they're exposed 
> by browser tools for web dev). This allows for them to be selectively 
> disabled, eg. to show BB without a button but with the native icon.

As far as I know I've only used 'binding' where it is necessary.

Note that <bb> only uses the binding if it's not empty.


> What is more important, is that appearance normatively defines what 
> properties from outside the appearance definition are allowed to 
> interfere with the native look of the widget, binding does not. If 
> author style sheets are not imported in XBL 
> (apply-author-sheets="false"), they don't apply at all.

I'm not sure what you mean when you say 'binding' doesn't define this -- 
as far as I can tell, XBL2 fully defines what should happen here.

We can't really know ahead of time whether the bindings should have 
apply-author-sheets="false" or "true", though.


> > The advantage of appearance vs binding is that:
> > > 1) you don't need an additional pass before applying the correct
> > > platform-specific widget style
> >
> > With UA-native bindings, you wouldn't need an additional pass either.
>
> The current spec says "User agents are encouraged to make their bindings 
> set the 'appearance' CSS property appropriately to achieve 
> platform-native appearances for widgets": this means that the binding 
> should set appearance, and then appearance should make the widget look 
> like a normal button.

I wouldn't characterise that as an extra pass, but ok. I don't think it's 
a problem.


> > > 2) you depend on css3-ui, in CR stage, instead of becss, a very 
> > > early WD
> >
> > BECSS is actually probably more stable than CSS3 UI at this point.
>
> Why do you say so? Will CSS3 UI go back to Last Call or BECSS process to 
> Last Call in the near future? I'm not sure. In the mean time, CSS3 UI is 
> final, and waiting only for implementation.

CSS3 UI is very vague, and is going to need serious work before browsers 
are able to actually implement it properly. A lot of the vendor feedback 
at the time it was written was dismissed (e.g. it doesn't have a 
particularly useful or comprehensive list of appearances).


> > > 3) you don't block the binding property: I don't expect that 
> > > applying an XBL binding on an element causes it to appear like a 
> > > span (because it gets almost no default CSS)
> >
> > This is actually intentional. Experience with elements like <fieldset> 
> > that have styles that aren't expressed in CSS is that you end up not 
> > being able to restyle them properly if you desire. With 'binding' we'd 
> > be able to knock out the whole default rendering (including weird 
> > things with the children) in one go.
>
> The fact is that binding it the best way to apply a set of event 
> handlers to an element. Having to tweak the computed style of a fieldset 
> in order to find what properties are actually set and reproduce them in 
> the binding, just to put a set of onchange handlers to lots of fieldset, 
> does not look optimal.

I don't understand why you would need to know what properties are set, or 
what 'onchange' has to do with anything here.


> > > 4) you keep the appearance property working: current UA (Firefox and 
> > > Safari at least) already implement appearance, and correctly set it 
> > > on the input element. This could no longer be possible using XBL, 
> > > because of the CSS inheritance model inside XBL (if you apply to 
> > > appearance to some part of the shadow tree, it is not visible on the 
> > > bound element)
> >
> > I don't understand what you mean here.
>
> I mean that Firefox and Safari set the appearance property on the widget 
> element, and it is visible from outside, and dynamically changeable at 
> run time. The binding property instead contains an opaque and UA 
> specific value, that is not intended to be changed from JS (to switch 
> back and forth between widget types)

I expect we'll define actual values for 'binding' in due course; that's 
mostly waiting on XBL2 getting implemented. I don't see why 'appearance' 
would work better with JS than 'binding'.


> > > 5) becss requires "one or more binding languages": it is not 
> > > necessarily XBL2, but currently XBL2 is the only one available: are 
> > > you constraining the implementation of HTML5 on that of XBL2?
> >
> > The rendering section has no actual requirements in it, so nothing is 
> > constrained. Furthermore, nothing requires the binding language used 
> > by the UA to actually be a real language, so long as it is triggered 
> > by the 'binding' property.
> 
> "A number of elements have their rendering defined in terms of the 'binding'
> property" (HTML5, with normative reference to BECSS)
> No BECSS --> no rendering --> no interoperability

But the rendering definitions are non-normative anyway.


> "A user agent cannot comply to this specification without also supporting
> one or more binding languages such as XBL" (BECSS, with informative
> reference to XBL2)
>
> Do you know any other binding languages outside XBL or HTC (that uses
> behaviour instead of binding)?

The browser can invent a fictional one for its own internal use.


> "*Computed Value:* specified value, with URIs resolved to absolute URIs 
> " "When a specified URI cannot be used, e.g. due to network errors or 
> because the specified binding is in an unsupported language, that 
> specified URI must be ignored, without affecting the other URIs 
> specified." This means that the binding property must be an absolute 
> <uri>, indicating a network retrievable resource (no about: or urn: URI) 
> in a supported language

We'll probably change that to just use keywords in due course.


On Sat, 7 Feb 2009, Giovanni Campagna wrote:
> 
> Yes, but UA that don't follow that set of CSS rules are not 
> interoperable with UA that follow, ie scripts must detect what 
> properties are ignored or defaulted.

Why would a script do that?


> > Furthermore, user agents are free to use any method they like to mimic 
> > the suggested rendering, including CSS3 UI where applicable. They 
> > don't have to use BE CSS at all.
> 
> They're "expected" to use CSS, and I expect that, according to html5, 
> "button { binding: initial; }" makes it like a <span>.

Right.


> > If this is not obvious from the text, perhaps you would like to 
> > suggest a change to the text that would make it clearer?
> 
> I don't agree with rendering being "optional". If interoperability is so 
> important (and it is), rendering should be normative. Obviously I'm not 
> asking to depend on CSS, I'm asking that "UA should act if the following 
> CSS was specified" (even if it doesn't support CSS)

That's basically what we have now, except that we can't make it any more 
normative because we don't know all the different ways that people will 
use HTML. Browsers are by far not the only way that people consume HTML, 
let alone desktop browsers with screens.


On Sat, 7 Feb 2009, Giovanni Campagna wrote:
> >
> > CSSOM-implementing UAs do not have to do express all styling with CSS 
> > properties.
> >
> > When they do, you can query for those properties via the CSSOM.
> 
> Yes, but what properties should I query for? Binding, behaviour, 
> appearance, border, color, font, all in once? And what should their 
> values be?

There is no way to say. The user could have a user style sheet that 
replaces all the default values anyway.


> If <input type="submit"> in some UA is rendered with all properties set to
> initial, not only it does not express the semantic of a button, but it may
> be difficult for a user to actually recognize it as a button and eventually
> click it. In that case I, as the author, may need to manually set {
> appearance:push-button; content:attr(value,string,"Send"); } in order to
> have my form submitted.
> Try this example (in Firefox or Safari):
> data:text/html,<style>label { position:fixed; top:-1em; border:1px solid
> black; } label input { -moz-appearance:none; -webkit-appearance:none;
> border:none; width:auto; } input[type=submit] { -moz-appearance:none;
> -webkit-appearance:none; background-color:transparent; border:none;
> }</style><form action="http://www.google.com/search"
> method="get"><label>Search: <input type="text" value=""
> name="q"></label><input type=submit value="Go">
> 
> Imagine that was the UA default stylesheet instead of an author 
> stylesheet and you may see what interoperability means with web 
> application look and feel.

Browsers that do that wouldn't be very usable. Is this a real concern? I 
mean, does any browser do this?


> HTML5 should not mandate the UA present <a>s in blue, but it should 
> mandate the UA present <a>s like links (appearance:hyperlink). The color 
> of course is a matter of visual themes and platform.

HTML5 actually does say links should be blue. :-)


> An other example: HTML5 should mandate <button> displayed with
> appearance:push-button; even if the UA doesn't support CSS.

It does: 

# When the button binding applies to a button element, the element is 
# expected to render as an 'inline-block' box rendered as a button whose 
# contents are the contents of the element.

Whether this means 'appearance: push-button', or some fancy combinations 
of borders, or something else entirely, is neither here nor there.


On Sun, 8 Feb 2009, Giovanni Campagna wrote:
> > >
> > > Yes, but what properties should I query for?
> >
> > In order to find out what, precisely?
>
> What to reset, for example (see the first Ian email on this topic)

Just reset everything? I really don't understand. Set the values you want, 
leave the rest alone, and the page will render fine. There's no need to 
"reset" anything.


On Sun, 8 Feb 2009, Giovanni Campagna wrote:
> 
> I agree with you that we must not constrain the innovation, but in that 
> case, what is the whole purpose of the Rendering section?

It's a guide to Web browser vendors who wish to render things in a 
commonly accepted way.


> I think that section is for
> - implementors of new UAs, that don't need to reverse engineer the
> competitor products in order to find the defaults

Right.


> - authors, that in this way know what to expect from the various UA with
> less testing, that sometimes is also impossible, eg. you cannot test the
> rendering of a mobile phone if you don't have a mobile phone
> Having somewhere written that hyperlinks should be blue, allows you to style
> the background-color to anything but blue.

The section is not really for authors (though I suppose authors might find 
it interesting, in the same way they might find the parser section 
interesting).


> If the UA suddenly displays hyperlinks in green and I decided that my
> background is green, the user will complain with me, not with the UA (and
> will probably switch to a different website)

Authors should never the background colour without setting the foreground 
colour. So that would be the author's fault.


> Having somewhere said that <table> should be rendered as CSS tables, allows
> you to put a border-collapse for example. If <table> suddenly starts to be
> displayed as an hierarchical tree, my site may be broken at once.

The spec does suggest using the CSS table model for tables. However, I 
don't see why if I, as a user, would rather navigate your table as a tree, 
I shouldn't be able to do so. It might not look like how you wanted it to, 
but that doesn't mean it's broken.


> The solutions are two:
> 1) either provide a default style sheets only for author and say: "you want
> the usual rendering everywhere? import this". This means that the whole
> Rendering sections should be moved to an Appendix and a separate
> downloadable CSS file should be provided. In addition the "presentational
> hints" become useless, since many of them cannot be expressed in terms of
> CSS, and actually, all UA default style sheets are less important, because
> most of time they will be overriden by author style sheets. Last, but not
> least, you have to face an increased traffic to load an heavy CSS file just
> for two or three display.
> 2) mandate a set of CSS properties and value.

I'm not convinced that there is a problem to solve.


On Mon, 9 Feb 2009, Giovanni Campagna wrote:
> 
> So the whole rendering section is just for implementors and authors 
> should act if no default style sheet is present or worse, if it could be 
> everything, like a inline-block <div> or blue <table>, so that the 
> author should set all supported properties to initial or the HTML5 
> "expected" value?

Authors should act as if the default style sheet is something sensible but 
they don't know what. (Because that is in fact what the situation is, once 
you consider user style sheets.)


> That is:
> I, author, want consistent rendering on all plaforms and browser:

Then you are going to be disappointed. This is not a supported goal.


> I, implementor, want to provide backward-compatible rendering for those
> author that didn't follow rule 1), I import HTML5 style sheet inside UA
> defaults.
> In both case, a downloadable stylesheet would be much appreciated.

There's no way to express the rendering section exclusively as CSS, so we 
can't provide code in that form.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From robert at ocallahan.org  Tue Feb 10 20:20:04 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 11 Feb 2009 17:20:04 +1300
Subject: [whatwg] Author control over media preloading/buffering
Message-ID: <11e306600902102020w785ea140v48e21304b96da8ef@mail.gmail.com>

When a media element loads, reaches the HAVE_CURRENT_DATA state, but is
paused, and 'autoplay' is not set, we have to decide whether to keep
downloading data or not. If we expect the user to play the stream, we should
keep downloading and buffering data to minimize the chance that buffering
will be needed during playback. But if we don't expect the user to play the
stream, we should pause the download to conserve resources. The latter is
especially important on pages with large numbers of media elements, only one
or two of which the user will play.

In general it's hard to see how to make a good guess automatically. If a
page has one (non-autoplay) media element on it, it's hard to know whether
the user is expected or not expected to play it. For example the user might
be expected to play it, but only after they've read some text before the
video (so autoplay is not appropriate). I think (but I'm not sure) that
authors are likely to be able to make better guesses, so I think it would be
useful to provide authors with control over this decision. I think that
authors are likely to want this control in the same way they like to be able
to preload images.

So, how about adding an "autobuffer" attribute, which instructs the browser
that the user will probably play the video and as much data as possible
should be pre-downloaded? By default (when the attribute is not present) the
browser would be expected to pause the download after reaching
HAVE_CURRENT_DATA if the media element is paused and not 'autoplay'.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090211/0330a1db/attachment.htm>

From simonp at opera.com  Tue Feb 10 21:04:26 2009
From: simonp at opera.com (Simon Pieters)
Date: Wed, 11 Feb 2009 06:04:26 +0100
Subject: [whatwg] Color attributes
In-Reply-To: <Pine.LNX.4.62.0902110022310.28232@hixie.dreamhostps.com>
References: <op.tu0hbhll7a8kvn@hp-a0a83fcd39d2>
	<op.ui38bralidj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0902110022310.28232@hixie.dreamhostps.com>
Message-ID: <op.uo58doqpidj3kv@zcorpandell.linkoping.osa>

On Wed, 11 Feb 2009 01:22:59 +0100, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 16 Oct 2008, Simon Pieters wrote:
>>
>> Color attributes in HTML have special processing. [...]
>>
>> It seems that some pages use three-digit notation and expect it to work
>> as in CSS. I've made the algorithm do that and I've drafted up a spec
>> for this:
>>
>>    http://simon.html5.org/specs/html-color-attributes
>
> The spec now defines this.

It seems the spec lacks the CSS2 system colors and 'transparent'.

-- 
Simon Pieters
Opera Software




From ian at hixie.ch  Wed Feb 11 00:20:42 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 08:20:42 +0000 (UTC)
Subject: [whatwg] False orthogonal nature :read-only and :disabled in WF2
In-Reply-To: <44E1A463.4010404@earthlink.net>
References: <43FAE36B.6000603@earthlink.net>
	<Pine.LNX.4.62.0608150029010.5340@dhalsim.dreamhost.com>
	<44E1A463.4010404@earthlink.net>
Message-ID: <Pine.LNX.4.62.0902110806580.28232@hixie.dreamhostps.com>

On Tue, 15 Aug 2006, Matthew Raymond wrote:
> Ian Hickson wrote:
> > I understand (and agree) that WF2 disagrees with CSS3UI and Selectors 
> > here. I believe the error is in CSS3UI and in Selectors.
> 
>    I would agree with that, although I think we disagree as to what the
> error is.
> 
> > Having them be orthogonal is far more useful to authors. For example, 
> > imagine the following stylesheet:
> > 
> >    :read-only::after { content: ' (Read-only)'; }
> >    :disabled { color: gray; }
> > 
> > You wouldn't want all the :disabled fields to suddenly say "read-only" 
> > just because they weren't relevant. You wouldn't want to have to say:
> > 
> >    :not(:disabled):read-only { ... }
> > 
> > ...every time you wanted to style the fields which, when enabled, still 
> > can't be edited.
> > 
> > I'll see if I can get Selectors updated.
> 
>    Please go back and address the concerns that I posted on www-style in
> detail when you update Selectors.

It turns out this is (now?) only in CSS3 UI, which doesn't have a 
maintainer right now.


> >> There is a clear double standard here. I had a problem with the way
> >> :read-only was defined, that it applied to elements that did not have a
> >> |readonly| attribute, but you made it clear that I would have to go
> >> through www-style to get it changes in the CSS3-UI specification before
> >> getting a related change made in the WF2 spec.
> > 
> > Well, :read-only has always been intended to apply to everything. There's 
> > a difference between the basic concept of the pseudo-class and the exact 
> > definiton of the pseudo-class.
> 
>    That's the point. The :read-only pseudo-class should never have been
> defined as applying to everything. It should apply to markup that has a
> defined read-only state. The text-based input of a control is not
> comparable to a |contenteditable| region of HTML. For instance, if you
> can't edit the markup of an <input> element, but you can edit the text
> in the control, then at the markup level, the control is read-only, but
> the actual control contents are read-write. Conversely, what if you have
> an <input readonly> control as the child of an element with
> |contenteditable| enabled? In this case, the markup actual says
> "readonly", but it might still be considered read-write because the
> markup can be changed.

I agree that I was applying a double standard here (I am following CSS3 
UI when it comes to it saying that :read-only applies to everything, and 
not following it when it comes to saying that :read-write doesn't apply 
to disabled controls).

I've made HTML5 say that :read-write doesn't apply to disabled controls.


> >> Yet when you have a problem with the definition of the 
> >> _EXACT_SAME_PSEUDO-CLASS_, you just change the WF2 spec to produce 
> >> orthogonally where none existed in the collective W3C specs.
> >>
> >> Perhaps you can explain to me how you justify this.
> > 
> > I'm trying to make the specs be useful to authors.
> 
>    Having to style control elements using selectors like
> "html|input[readonly]" as opposed to ":readonly" doesn't strike me as
> more useful for authors. Also, note that for stuff like XForms, you can
> end up in a situation where there's no clear way of styling a
> "read-only" control, since the "read-only" property may not exist
> directly on the element. Of course, if we start talking about other XML
> languages here, we're getting off topic...

Yeah. I'm not really sure what to do about this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Feb 11 00:39:27 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 08:39:27 +0000 (UTC)
Subject: [whatwg] Styling of area elements (as displayed within
 referencing image)
In-Reply-To: <20070510182121.GA4117@ridley.dbaron.org>
References: <20070510182121.GA4117@ridley.dbaron.org>
Message-ID: <Pine.LNX.4.62.0902110838000.28232@hixie.dreamhostps.com>

On Thu, 10 May 2007, L. David Baron wrote:
>
> The interaction of area elements with CSS styling is not defined in HTML 
> 5.  Since area elements are particularly unusual (in that they appear an 
> arbitrary number of times, whenever their containing map is linked to by 
> an img), I think it should be.

Fixed. Please let me know if the new text is ok:

   http://www.whatwg.org/specs/web-apps/current-work/#image-maps-0

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Feb 11 00:41:03 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 08:41:03 +0000 (UTC)
Subject: [whatwg] [wf2] :read-write pseudoclass description issue
In-Reply-To: <46FC6741.30700@earthlink.net>
References: <46F7AA4B.5060505@finalist.com>
	<1190637106.46f7ae32b08e9@sam.opera.com>
	<46FC6741.30700@earthlink.net>
Message-ID: <Pine.LNX.4.62.0902110839350.28232@hixie.dreamhostps.com>

On Mon, 24 Sep 2007, Rikkert Koppes wrote:
>
> http://www.whatwg.org/specs/web-forms/current-work/#relation
> 
> :read-only
>    Matches form control elements that have the |readonly
>    <http://www.whatwg.org/specs/web-forms/current-work/#readonly>|
>    attribute set, and to which the |readonly
>    <http://www.whatwg.org/specs/web-forms/current-work/#readonly>|
>    attribute applies (thus radio buttons will never match this,
>    regardless of the value of the attribute), as well as elements
>    defined by this specification that are not form controls (namely
>    |form|, |label|, |datalist
>    <http://www.whatwg.org/specs/web-forms/current-work/#datalist>|,
>    |option|, |optgroup|, and |fieldset| elements). :read-write
>    Matches form control elements that do not have the |readonly
>    <http://www.whatwg.org/specs/web-forms/current-work/#readonly>|
>    attribute set (including |password
>    <http://www.whatwg.org/specs/web-forms/current-work/#password>|
>    controls, although technically they should be called "writeonly"),
>    or to which the attribute doesn't apply (such as radio buttons). A
>    disabled control can still match this pseudo-class; the states are
>    orthogonal.
> 
> I believe the term "orthogonal" is incorrect here. Following (the rest of) the
> text, it occurs to me these pseusoclasses are opposite (mutually exclusive),
> while orthogonal means, they can both apply, independent of eachother.

The new text doesn't mention this. Let me know if it's ok:

  http://www.whatwg.org/specs/web-apps/current-work/#matching-html-elements-using-selectors

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Feb 11 01:25:09 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 09:25:09 +0000 (UTC)
Subject: [whatwg] [wf2] :read-write pseudoclass description issue
In-Reply-To: <49929712.1060204@finalist.com>
References: <46F7AA4B.5060505@finalist.com>
	<1190637106.46f7ae32b08e9@sam.opera.com>
	<46FC6741.30700@earthlink.net>
	<Pine.LNX.4.62.0902110839350.28232@hixie.dreamhostps.com>
	<49929712.1060204@finalist.com>
Message-ID: <Pine.LNX.4.62.0902110920140.952@hixie.dreamhostps.com>

On Wed, 11 Feb 2009, Rikkert Koppes wrote:
> 
> However, reading the previous text (in the quoted mail below) again, it 
> occurs to me that was actually intended was "A disabled control can 
> still match this pseudo-class; the [disabled and read-write] states are 
> orthogonal."
> 
> In that sense, the current text is quite a shift.

Yeah, this was done to line up more closely with CSS3 UI's definitions. I 
don't really think they make sense, but it's not HTML5's place to go 
against what the CSSWG decided.


> furthermore, some text remarks at [1]
> - on the read-write definition, first bullet, immutable already includes
> disabled controls [2]

Fixed.


> text remarks at [2]
> - on the note ("The readonly attribute can also in some cases make an input
> element immutable."): in which cases not? [3] seems to imply all cases, this
> should be made clear at the note.

It doesn't, e.g., make a radio button immutable. I'm not sure how to make 
it clearer without repeating spec text over and over though.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Feb 11 01:45:53 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 09:45:53 +0000 (UTC)
Subject: [whatwg] [wf2] :read-write pseudoclass description issue
In-Reply-To: <49929B9C.9030001@rikkertkoppes.com>
References: <46F7AA4B.5060505@finalist.com>
	<1190637106.46f7ae32b08e9@sam.opera.com>
	<46FC6741.30700@earthlink.net>
	<Pine.LNX.4.62.0902110839350.28232@hixie.dreamhostps.com>
	<49929712.1060204@finalist.com>
	<Pine.LNX.4.62.0902110920140.952@hixie.dreamhostps.com>
	<49929B9C.9030001@rikkertkoppes.com>
Message-ID: <Pine.LNX.4.62.0902110938150.952@hixie.dreamhostps.com>

On Wed, 11 Feb 2009, Rikkert Koppes wrote:
>
> At [1] I'd suggest changing the second sentence to "When specified and 
> applicable, the element is immutable".
> 
> [1]: http://www.whatwg.org/specs/web-apps/current-work/#attr-input-readonly

Yeah, I keep thinking of doing something like that. The reason I haven't 
yet is that I don't want to go down the route of people seeing that and 
thinking that that means that other things in that section might apply 
even when they don't (the intro to that section explicitly says that 
nothing there applies if the attributes aren't applicable).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From lists at rikkertkoppes.com  Wed Feb 11 02:22:14 2009
From: lists at rikkertkoppes.com (Rikkert Koppes)
Date: Wed, 11 Feb 2009 11:22:14 +0100
Subject: [whatwg] [wf2] :read-write pseudoclass description issue
In-Reply-To: <Pine.LNX.4.62.0902110938150.952@hixie.dreamhostps.com>
References: <46F7AA4B.5060505@finalist.com>
	<1190637106.46f7ae32b08e9@sam.opera.com>
	<46FC6741.30700@earthlink.net>
	<Pine.LNX.4.62.0902110839350.28232@hixie.dreamhostps.com>
	<49929712.1060204@finalist.com>
	<Pine.LNX.4.62.0902110920140.952@hixie.dreamhostps.com>
	<49929B9C.9030001@rikkertkoppes.com>
	<Pine.LNX.4.62.0902110938150.952@hixie.dreamhostps.com>
Message-ID: <4992A6D6.9070900@rikkertkoppes.com>

I see your point, to go for another route, maybe you'd just edit the 
source of the problem (the note), remove it and include a text similar 
to the remark about the disabled attribute. I.e:
-------
When an input element is disabled, it is immutable.
When an input element is readonly, it is immutable.
-------
However, there is no readonly concept defined (maybe this will clarify 
more, but actually I think it's likely to complicate things even more). 
Hence, another suggestion could be:
-------
An input element to which the readonly attribute applies and has that 
attribute specified, is immutable.
-------

Cheers,
Rikkert Koppes

Ian Hickson wrote:
> On Wed, 11 Feb 2009, Rikkert Koppes wrote:
>   
>> At [1] I'd suggest changing the second sentence to "When specified and 
>> applicable, the element is immutable".
>>
>> [1]: http://www.whatwg.org/specs/web-apps/current-work/#attr-input-readonly
>>     
>
> Yeah, I keep thinking of doing something like that. The reason I haven't 
> yet is that I don't want to go down the route of people seeing that and 
> thinking that that means that other things in that section might apply 
> even when they don't (the intro to that section explicitly says that 
> nothing there applies if the attributes aren't applicable).
>
>   


From ian at hixie.ch  Wed Feb 11 02:35:21 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 10:35:21 +0000 (UTC)
Subject: [whatwg] [wf2] :read-write pseudoclass description issue
In-Reply-To: <4992A6D6.9070900@rikkertkoppes.com>
References: <46F7AA4B.5060505@finalist.com>
	<1190637106.46f7ae32b08e9@sam.opera.com>
	<46FC6741.30700@earthlink.net>
	<Pine.LNX.4.62.0902110839350.28232@hixie.dreamhostps.com>
	<49929712.1060204@finalist.com>
	<Pine.LNX.4.62.0902110920140.952@hixie.dreamhostps.com>
	<49929B9C.9030001@rikkertkoppes.com>
	<Pine.LNX.4.62.0902110938150.952@hixie.dreamhostps.com>
	<4992A6D6.9070900@rikkertkoppes.com>
Message-ID: <Pine.LNX.4.62.0902111031470.952@hixie.dreamhostps.com>

On Wed, 11 Feb 2009, Rikkert Koppes wrote:
>
> I see your point, to go for another route, maybe you'd just edit the source of
> the problem (the note), remove it and include a text similar to the remark
> about the disabled attribute. I.e:
> -------
> When an input element is disabled, it is immutable.
> When an input element is readonly, it is immutable.
> -------
> However, there is no readonly concept defined (maybe this will clarify more,
> but actually I think it's likely to complicate things even more). Hence,
> another suggestion could be:
> -------
> An input element to which the readonly attribute applies and has that
> attribute specified, is immutable.

The problem with those is that the requirement in question is already in 
the readonly section, along with some more requirements, and I don't want 
to split the requirements up to be all over the place...

Instead I've annotated the note a little to make it slightly clearer why 
it's only "sometimes". Does that help?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Feb 11 02:46:56 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 10:46:56 +0000 (UTC)
Subject: [whatwg] <code> in "in body" insertion mode (8.2.5)
In-Reply-To: <20090116180808.B1CAF14DA06@looneymail-mx2.g.dreamhost.com>
References: <20090116180808.B1CAF14DA06@looneymail-mx2.g.dreamhost.com>
Message-ID: <Pine.LNX.4.62.0902111046410.28232@hixie.dreamhostps.com>

On Mon, 12 Jan 2009, Kartikaya Gupta wrote:
>
> "code" is listed in the formatting category of elements, but isn't dealt 
> with in the same way as other formatting elements when in the "in body" 
> insertion mode. Currently it will fall through to the "any other start 
> tag" case, so the note in that case that says "This element will be a 
> phrasing element" is incorrect.
> 
> I'm assuming that the "code" element should be listed along with the 
> other formatting elements (b, big, em, etc.) for the "in body" insertion 
> mode. Is that correct?

On Fri, 16 Jan 2009, Kartikaya Gupta wrote:
> 
> Oh, it's also missing from the end tags section (i.e. </code> when in 
> body insertion mode).

Fixed. Thanks.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From Simetrical+w3c at gmail.com  Wed Feb 11 03:37:00 2009
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 11 Feb 2009 06:37:00 -0500
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
	<498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
	<20090209142419.GA2461@stripey.com>
	<65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>
	<Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>
Message-ID: <7c2a12e20902110337u626c67b7p8e1a2b4aa63ec67a@mail.gmail.com>

On Tue, Feb 10, 2009 at 10:30 PM, Ian Hickson <ian at hixie.ch> wrote:
>> If the UA suddenly displays hyperlinks in green and I decided that my
>> background is green, the user will complain with me, not with the UA (and
>> will probably switch to a different website)
>
> Authors should never the background colour without setting the foreground
> colour. So that would be the author's fault.

I don't think that's relevant.  If I, as an author, use the rule

body { color: white; background: green; }

and the UA uses the rule

:link { color: green; }

then links would be invisible despite my background color.  Although
authors are encouraged to always set colors and backgrounds together,
UAs conventionally do *not* do this for links, for fairly good reason.

You could say that not only should authors never set the background
color without setting the foreground color, they should also never set
the background color without setting the *link* color.  But this still
doesn't help if the UA (or a user stylesheet) uses

span { color: green; }

for some strange reason (not much stranger than green links by
default!), in which case everything is still messed up.

I don't think there's any way around this.  If a UA sets unexpected
style rules, it *will* break some sites.  I imagine that the response
to this is that while this may be so, it's possible that in some cases
it will be a tradeoff against platform integration or something, and
so it should still be up to the implementers to decide whether it's a
good tradeoff in their case.  The expectation would be that for
conventional browsers, it won't be.  This is pretty much just the
definition of "should" in RFC2119.


From Smylers at stripey.com  Wed Feb 11 05:36:45 2009
From: Smylers at stripey.com (Smylers)
Date: Wed, 11 Feb 2009 13:36:45 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <7c2a12e20902110337u626c67b7p8e1a2b4aa63ec67a@mail.gmail.com>
References: <498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
	<498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
	<20090209142419.GA2461@stripey.com>
	<65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>
	<Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>
	<7c2a12e20902110337u626c67b7p8e1a2b4aa63ec67a@mail.gmail.com>
Message-ID: <20090211133645.GA20994@stripey.com>

Aryeh Gregor writes:

> On Tue, Feb 10, 2009 at 10:30 PM, Ian Hickson <ian at hixie.ch> wrote:
> 
> > > If the UA suddenly displays hyperlinks in green and I decided that
> > > my background is green, the user will complain with me, not with
> > > the UA (and will probably switch to a different website)
> > 
> > Authors should never the background colour without setting the
> > foreground colour. So that would be the author's fault.
> 
> I don't think that's relevant.

It is relevant, because as you then say:

> If I, as an author, use the rule
> 
> body { color: white; background: green; }
> 
> and the UA uses the rule
> 
> :link { color: green; }
> 
> then links would be invisible despite my background color.

That is precisely an instance of an author setting a background colour
without a foreground colour -- specifically the author set the
background colour used on links without setting the foreground colour
for links.

If an author sets a background colour then she needs to set the
foreground colour for all text that appears on it, anywhere.

> Although authors are encouraged to always set colors and backgrounds
> together, UAs conventionally do *not* do this for links, for fairly
> good reason.

Browsers do of course (typically) set both together -- in that they
provide a default background colour, plus foreground colours for visited
links, unvisitied links, and non-link text.  If an author overrides one
of those four then he generally needs to override all of them (except in
circumstances where he knows the area in question won't have any links,
or any-non links, or any text).

> You could say that not only should authors never set the background
> color without setting the foreground color, they should also never set
> the background color without setting the *link* color.

Yup.

> But this still doesn't help if the UA (or a user stylesheet) uses
> 
> span { color: green; }
> 
> for some strange reason

Indeed.  That would be strange.  So strange that I really don't see why
HTML 5 should be concerned with it, and I certainly don't think there's
anything it can do about it:

* A user-agent that does something as arbitrary as the above is unlikely
  to achieve much market share.

* A user style-sheet that does the above has been presumably set by a
  user who wants it.  Let her.

> (not much stranger than green links by default!),

It's significantly stranger, for a couple of reasons:

* Links are a distinct type of element with a specific purpose.
  <span>-s convey no semantics of their own, and are used for multiple
  purposes.

* Links are conventionally a different colour from other text; <span>-s
  aren't.  Prefering links to be green rather than blue is a minor
  change, possibly one of aesthetics or to assist somebody who has
  trouble distinguishing certain colours.  Whereas prefering <span>-s to
  be green rather than indistinguishable from the surrounding text is
  adding in a distinction not normally seen.

> in which case everything is still messed up.

Yes.  Users can choose to implement custom styles which mess things up.
Users are free to do that if they want.

They may even have good reasons for doing so; for example, when
attempting to debug a website it can be useful to make various elements
different colours to show which is rendered where.  It's possible that
at some point I want to debug your website, or examine how you achieved
a particular effect, and that making your <span>-s green will assist me
in doing that.

> I don't think there's any way around this.

We don't want a way "round" it.  It's a feature that users are in
ultimate control.

Smylers


From Simetrical+w3c at gmail.com  Wed Feb 11 06:33:51 2009
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 11 Feb 2009 09:33:51 -0500
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <20090211133645.GA20994@stripey.com>
References: <498DE005.2070502@googlemail.com>
	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
	<498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
	<20090209142419.GA2461@stripey.com>
	<65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>
	<Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>
	<7c2a12e20902110337u626c67b7p8e1a2b4aa63ec67a@mail.gmail.com>
	<20090211133645.GA20994@stripey.com>
Message-ID: <7c2a12e20902110633j1f6cdcav8f1b7c23c4fa62b4@mail.gmail.com>

On Wed, Feb 11, 2009 at 8:36 AM, Smylers <Smylers at stripey.com> wrote:
> That is precisely an instance of an author setting a background colour
> without a foreground colour -- specifically the author set the
> background colour used on links without setting the foreground colour
> for links.
>. . .
> Browsers do of course (typically) set both together -- in that they
> provide a default background colour, plus foreground colours for visited
> links, unvisitied links, and non-link text.

I interpret "authors should always set background and foreground
colors together" as "no single CSS rule should set 'background'
without setting 'color' or vice versa".  I can't figure out exactly
how you're interpreting it.

The point is that to ensure that the foreground and background don't
conflict, you must always set foreground and background colors *in the
same CSS rule*.  As long as all stylesheets observe this principle,
there will never be a mismatch.  Either the color and background are
overridden both at once, or not at all, since the cascade works on a
rule-by-rule basis, not property-by-property.

The browser is the one that's failing to observe the principle in this
case, and the author is observing it.  The author is *not* setting the
background color for :link, nor the foreground color.  The author is
only setting the colors for body.  On the other hand, the UA is
setting the foreground color for :link, but is *not* setting a
background color for :link -- only for body.  If you put the rule
":link { color: blue; }" into the W3C CSS validator, it will warn you
that you're setting color without setting background, regardless of
whether there's any inherited color you've set.

> If an author overrides one
> of those four then he generally needs to override all of them (except in
> circumstances where he knows the area in question won't have any links,
> or any-non links, or any text).

So you're saying links are a special case for this principle?  Why?
UAs might just as reasonably change the colors of other elements as
well.  It's only convention that says they only change the color of
links.  But that exact same convention says that the color of links is
blue.

> It's significantly stranger, for a couple of reasons:
>
> * Links are a distinct type of element with a specific purpose.
>  <span>-s convey no semantics of their own, and are used for multiple
>  purposes.

So instead, suppose it were something like:

strong { color: red; }

In fact, though, green spans would not be significantly less common in
UA default stylesheets than green links -- as far as I know, neither
has ever occurred, certainly not in a notable browser.  That's what I
meant by saying it would be "not much stranger".  Conceptually it's
stranger, but practically it's not.

> * Links are conventionally a different colour from other text; <span>-s
>  aren't.  Prefering links to be green rather than blue is a minor
>  change, possibly one of aesthetics or to assist somebody who has
>  trouble distinguishing certain colours.  Whereas prefering <span>-s to
>  be green rather than indistinguishable from the surrounding text is
>  adding in a distinction not normally seen.

Yes, links are conventionally a different color from other text.  More
particularly, they're conventionally *blue*.  Every color browser I
have ever heard of back to the dawn of the Web uses blue for links.
NCSA Mosaic 0.6 beta already used blue for links:

http://gladiator.ncsa.uiuc.edu/Images/press-images/mosaic.6beta.tif

I have never heard of any exception.  If you're saying that authors
should expect browsers to behave conventionally in not changing the
colors of non-links, I can't see how you would say that authors
shouldn't expect them to behave conventionally in making links blue.
Either the UAs are adopting the universal standards that everyone
everywhere has always used, or they're doing heaven knows what.

> Yes.  Users can choose to implement custom styles which mess things up.
> Users are free to do that if they want.

We aren't talking about user stylesheets here, we're talking about
browser default stylesheets.  HTML5 does not mention user stylesheets,
as far as I'm aware.

> We don't want a way "round" it.

We always want a way around the possibility of sites breaking due to
different assumptions between UA and author.  That's what standards
are *for*.  In this case, however, it's not feasible to mandate a
single default rendering for all UAs.  Clearly text-based browsers,
monochrome browsers, screen readers, etc. need to use different rules.
 Therefore sites will sometimes break in browsers they weren't
designed for, and this is unfortunate, but it's not something HTML5
can prevent.


From bzbarsky at MIT.EDU  Wed Feb 11 06:44:38 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 11 Feb 2009 09:44:38 -0500
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <20090211133645.GA20994@stripey.com>
References: <498DE005.2070502@googlemail.com>	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>	<20090208134044.GA3459@stripey.com>	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>	<498F1B63.5030603@googlemail.com>	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>	<20090209142419.GA2461@stripey.com>	<65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>	<Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>	<7c2a12e20902110337u626c67b7p8e1a2b4aa63ec67a@mail.gmail.com>
	<20090211133645.GA20994@stripey.com>
Message-ID: <4992E456.8050606@mit.edu>

Smylers wrote:
> That is precisely an instance of an author setting a background colour
> without a foreground colour -- specifically the author set the
> background colour used on links without setting the foreground colour
> for links.
> 
> If an author sets a background colour then she needs to set the
> foreground colour for all text that appears on it, anywhere.

Sorry, but that's just not reasonable.  Especially because some of the 
text is not even stylable directly by the author (but might be by the UA 
stylesheet).

-Boris


From Smylers at stripey.com  Wed Feb 11 07:13:53 2009
From: Smylers at stripey.com (Smylers)
Date: Wed, 11 Feb 2009 15:13:53 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <7c2a12e20902110633j1f6cdcav8f1b7c23c4fa62b4@mail.gmail.com>
References: <20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
	<498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
	<20090209142419.GA2461@stripey.com>
	<65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>
	<Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>
	<7c2a12e20902110337u626c67b7p8e1a2b4aa63ec67a@mail.gmail.com>
	<20090211133645.GA20994@stripey.com>
	<7c2a12e20902110633j1f6cdcav8f1b7c23c4fa62b4@mail.gmail.com>
Message-ID: <20090211151353.GD20994@stripey.com>

Aryeh Gregor writes:

> On Wed, Feb 11, 2009 at 8:36 AM, Smylers <Smylers at stripey.com> wrote:
> 
> > That is precisely an instance of an author setting a background
> > colour without a foreground colour -- specifically the author set
> > the background colour used on links without setting the foreground
> > colour for links.
> >. . .
> > Browsers do of course (typically) set both together -- in that they
> > provide a default background colour, plus foreground colours for
> > visited links, unvisitied links, and non-link text.
> 
> I interpret "authors should always set background and foreground
> colors together" as "no single CSS rule should set 'background'
> without setting 'color' or vice versa".  I can't figure out exactly
> how you're interpreting it.

Ah, I see.  Thanks for explaining that.  I'm interpreting it as "for
each bit of text that you cause the background colour to be set for,
also specify its foreground colour (and _vice versa_)".

So it's reasonable for a browser to set a background colour on <body>
and know that other elements take their background from that.

> The point is that to ensure that the foreground and background don't
> conflict, you must always set foreground and background colors *in the
> same CSS rule*.  As long as all stylesheets observe this principle,
> there will never be a mismatch.

True, but that introduces other awkwardnesses.  Given that many pages
(or regions of pages) have a background colour shared across several
elements, it's tedious to have to specify it for each one -- and also
harder to change.

If the default browser style-sheet explicitly specified the background
colour for links (rather than letting the <body> background show
through) then authors would have to override all of them, instead of
just the <body> colour.  I expect that would break many existing
websites.

> Either the color and background are overridden both at once, or not at
> all, since the cascade works on a rule-by-rule basis, not
> property-by-property.

On that basis transparent backgrounds are useless, since you can never
be sure that somebody else won't change the background colour of the
parent element without ensuring none of its content's text colours
clash.

HTML elements nest.  People expect that setting a background on an
elment makes it appear behind all nested elments it contains.  Let's
work with that, not against it.

> The browser is the one that's failing to observe the principle in this
> case, and the author is observing it.  The author is *not* setting the
> background color for :link, nor the foreground color.

However she's including link elements inside a <body> for which she has
set a background colour.  Therefore, by my understanding, she's
specified a background colour without a foreground colour.

Your interpretation and my interpretation both 'work'.  However, mine's
less hassle to deal with (avoids proliferation of repetitive properties)
and compatible with the extant web.

> > If an author overrides one of those four then he generally needs to
> > override all of them (except in circumstances where he knows the
> > area in question won't have any links, or any-non links, or any
> > text).
> 
> So you're saying links are a special case for this principle?  Why?

Yes.  Because links typically have a different colour -- as defined in
the expected styling information given in HTML 5, and therefore authors
should expect it.

> UAs might just as reasonably change the colors of other elements as
> well.  It's only convention that says they only change the color of
> links.

Yes.  Conventions are good.

> But that exact same convention says that the color of links is blue.

Fair point.  But browsers have for a long time provided UI for users to
specify other link colours in way that they haven't, for exmaple, the
colour of headings or emphasized text.  I'm sure some users take
advantage of such UI (and wouldn't consider them to be user
style-sheets; somebody clicking on such UI possibly isn't even aware of
the concept of user style-sheets).

There are plausible reasons why a user would want to set non-default
colours, perhaps to make things easier to read.  And if he sets a
different text and background colour, he's likely to want to set
different link colours too, so that they still stand out.

Smylers


From Simetrical+w3c at gmail.com  Wed Feb 11 07:41:12 2009
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 11 Feb 2009 10:41:12 -0500
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <20090211151353.GD20994@stripey.com>
References: <20090208134044.GA3459@stripey.com>
	<498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
	<20090209142419.GA2461@stripey.com>
	<65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>
	<Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>
	<7c2a12e20902110337u626c67b7p8e1a2b4aa63ec67a@mail.gmail.com>
	<20090211133645.GA20994@stripey.com>
	<7c2a12e20902110633j1f6cdcav8f1b7c23c4fa62b4@mail.gmail.com>
	<20090211151353.GD20994@stripey.com>
Message-ID: <7c2a12e20902110741j18bc4f3dlf83adb1d7ca853f5@mail.gmail.com>

On Wed, Feb 11, 2009 at 10:13 AM, Smylers <Smylers at stripey.com> wrote:
> Ah, I see.  Thanks for explaining that.  I'm interpreting it as "for
> each bit of text that you cause the background colour to be set for,
> also specify its foreground colour (and _vice versa_)".

But that's not *possible* in CSS.  Not within reason, anyway.  You
can't be expected to set color for all descendants.

> True, but that introduces other awkwardnesses.  Given that many pages
> (or regions of pages) have a background colour shared across several
> elements, it's tedious to have to specify it for each one -- and also
> harder to change.

It's the only way to be *sure* that things won't break (at least, you
can be sure as long as everyone does it).

> On that basis transparent backgrounds are useless, since you can never
> be sure that somebody else won't change the background colour of the
> parent element without ensuring none of its content's text colours
> clash.

Transparent backgrounds (i.e., no background) can still be set safely
if you don't specify the text color.  You only need to set the
background when you set the text color.

In practice, of course, this still isn't necessarily feasible.  E.g.,
there may be a complicated background-image on body, which you can't
respecify on descendants because it wouldn't line up properly.  Then
if you want to change the color of elements, you have to do it with a
nonexistent (transparent) background.  This means you'll have to
accept the risk of things breaking if the user specifies a different
style.

> Your interpretation and my interpretation both 'work'.  However, mine's
> less hassle to deal with (avoids proliferation of repetitive properties)
> and compatible with the extant web.

Well, what you call "my" interpretation is also the interpretation of
whoever wrote the W3C CSS validator, AFAICT.  It's *not* safe to set
foreground color without background or vice versa, at least if you
assume that your CSS might interact with arbitrary CSS from other
sources.  It may sometimes (even often) be worth the risk, however.

I would say that what you're suggesting is an entirely different
principle: stylesheet authors should manually set :link, :visited, and
:hover foreground colors if they set any background color on any
element that might contain a link, because they can't guarantee UA
behavior otherwise.  This is a much more specific point -- it doesn't
cover interaction with author or user stylesheets and requires at most
three rules per set of stylesheets.

> Fair point.  But browsers have for a long time provided UI for users to
> specify other link colours in way that they haven't, for exmaple, the
> colour of headings or emphasized text.  I'm sure some users take
> advantage of such UI (and wouldn't consider them to be user
> style-sheets; somebody clicking on such UI possibly isn't even aware of
> the concept of user style-sheets).

Good point.  I just checked and Firefox does in fact have such an
option.  So I'll agree that authors should always specify link colors
to override the UA's stylesheet, if they specify backgrounds.  My
objection to what Ian said was incorrect.


From Smylers at stripey.com  Wed Feb 11 07:54:17 2009
From: Smylers at stripey.com (Smylers)
Date: Wed, 11 Feb 2009 15:54:17 +0000
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <7c2a12e20902110741j18bc4f3dlf83adb1d7ca853f5@mail.gmail.com>
References: <498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
	<20090209142419.GA2461@stripey.com>
	<65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>
	<Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>
	<7c2a12e20902110337u626c67b7p8e1a2b4aa63ec67a@mail.gmail.com>
	<20090211133645.GA20994@stripey.com>
	<7c2a12e20902110633j1f6cdcav8f1b7c23c4fa62b4@mail.gmail.com>
	<20090211151353.GD20994@stripey.com>
	<7c2a12e20902110741j18bc4f3dlf83adb1d7ca853f5@mail.gmail.com>
Message-ID: <20090211155417.GE20994@stripey.com>

Aryeh Gregor writes:

> On Wed, Feb 11, 2009 at 10:13 AM, Smylers <Smylers at stripey.com> wrote:
> 
> > Ah, I see.  Thanks for explaining that.  I'm interpreting it as "for
> > each bit of text that you cause the background colour to be set for,
> > also specify its foreground colour (and _vice versa_)".
> 
> But that's not *possible* in CSS.  Not within reason, anyway.  You
> can't be expected to set color for all descendants.

You're right.  It is possible if you presume foreground colours
generally inherit (except for links) and backgrounds are generally
transparent.  Which apparently I was presuming, but omitted to state.
Sorry for not thinking it through properly.

> > True, but that introduces other awkwardnesses.  Given that many
> > pages (or regions of pages) have a background colour shared across
> > several elements, it's tedious to have to specify it for each one --
> > and also harder to change.
> 
> It's the only way to be *sure* that things won't break (at least, you
> can be sure as long as everyone does it).

We can be sure that there are live websites out there currently not
doing it!

For a start, there are those which don't use CSS at all but on <body>
set the bgcolor, text, link, and vlink attributes (another reason why
links are special, since there aren't similar attributes for setting any
other elements' colours).

> I would say that what you're suggesting is an entirely different
> principle: stylesheet authors should manually set :link, :visited, and
> :hover foreground colors if they set any background color on any
> element that might contain a link, because they can't guarantee UA
> behavior otherwise.  This is a much more specific point -- it doesn't
> cover interaction with author or user stylesheets and requires at most
> three rules per set of stylesheets.

Yes.  And also the reverse (that if you set a link colour then set the
background colour on either links or an ancestor element).

> I'll agree that authors should always specify link colors to override
> the UA's stylesheet, if they specify backgrounds.

Hurrah -- in that case I think we're in agreement, and no changes to the
spec are necessary.

Smylers


From bzbarsky at MIT.EDU  Wed Feb 11 09:53:40 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 11 Feb 2009 12:53:40 -0500
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <E1LXJ35-0002nf-LM@maggie.w3.org>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
Message-ID: <499310A4.5060301@mit.edu>

Kartikaya Gupta wrote:
>> For Java, DOMTimeStamp is bound to the long type. For ECMAScript,
>> DOMTimeStamp is bound to the Date type because the range of the
>> integer type is too small.
> 
> I get "number" in Opera and Firefox, and "object" in Webkit. Is there
> a reason Opera and Firefox bind the timestamps to numbers instead of
> the Date object?

In the case of Gecko, simply because no one wrote the code to do it, I 
suspect.

> Are there any websites that depend on this behavior?

Given the bugs Gecko has had with timeStamp (starting with inconsistent 
units for it), I doubt sites depend on anything much here.

> Also, I'm not sure if WebIDL should say something for this; right now
> the DOM IDL files do a "typedef unsigned long long DOMTimeStamp",
> which corresponds to the Java binding but not the ECMAScript binding.

Yep.  That's exactly the IDL Gecko uses.

-Boris


From darin at apple.com  Wed Feb 11 10:06:14 2009
From: darin at apple.com (Darin Adler)
Date: Wed, 11 Feb 2009 10:06:14 -0800
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <E1LXJ35-0002nf-LM@maggie.w3.org>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
Message-ID: <6AACBF67-F82E-432E-9ACC-1376F1902E9E@apple.com>

On Feb 11, 2009, at 9:38 AM, Kartikaya Gupta wrote:

> DOM 3 Core says this about DOMTimeStamp:
>
>> For Java, DOMTimeStamp is bound to the long type. For ECMAScript,  
>> DOMTimeStamp
>> is bound to the Date type because the range of the integer type is  
>> too small.
>
> However, when I do this:
>
>> var e = document.createEvent('Events');
>> alert( typeof e.timeStamp );
>
> I get "number" in Opera and Firefox, and "object" in Webkit.

I get "number" in WebKit.

     -- Darin



From lists.webapps at stakface.com  Wed Feb 11 10:51:09 2009
From: lists.webapps at stakface.com (Kartikaya Gupta)
Date: Wed, 11 Feb 2009 18:51:09 +0000
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <6AACBF67-F82E-432E-9ACC-1376F1902E9E@apple.com>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
	<6AACBF67-F82E-432E-9ACC-1376F1902E9E@apple.com>
Message-ID: <20090211185110.29CDE14D8C6@looneymail-mx2.g.dreamhost.com>

On Wed, 11 Feb 2009 10:06:14 -0800, Darin Adler <darin at apple.com> wrote:
> > 
> > However, when I do this:
> > 
> > > var e = document.createEvent('Events');
> > > alert( typeof e.timeStamp );
> > 
> > I get "number" in Opera and Firefox, and "object" in Webkit.
> 
> I get "number" in WebKit.
> 
>      -- Darin
> 
> 

Interesting. What version did you try on? I used Chrome 1.0.154.48 and Safari 3.1 (525.13) on Windows.

Cheers,
kats


From darin at apple.com  Wed Feb 11 10:58:00 2009
From: darin at apple.com (Darin Adler)
Date: Wed, 11 Feb 2009 10:58:00 -0800
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <20090211185112.4F94D28085@mail-in11.apple.com>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
	<6AACBF67-F82E-432E-9ACC-1376F1902E9E@apple.com>
	<20090211185112.4F94D28085@mail-in11.apple.com>
Message-ID: <162ED70B-388B-4FC1-9130-D796543F8D03@apple.com>

On Feb 11, 2009, at 10:51 AM, Kartikaya Gupta wrote:

> Interesting. What version did you try on? I used Chrome 1.0.154.48  
> and Safari 3.1 (525.13) on Windows.

The relevant version is the WebKit version rather than the Safari  
version. They have separate version numbers.

I used WebKit/525.27.1 (the version that came with Safari 3.1.1) on  
Mac OS X and also WebKit tip of tree on Mac OS X.

I also inspected the code and saw nothing that would create an object  
in the JavaScript binding for this.

     -- Darin



From dbaron at dbaron.org  Wed Feb 11 11:36:25 2009
From: dbaron at dbaron.org (L. David Baron)
Date: Wed, 11 Feb 2009 11:36:25 -0800
Subject: [whatwg] Styling of area elements (as displayed
	within	referencing image)
In-Reply-To: <Pine.LNX.4.62.0902110838000.28232@hixie.dreamhostps.com>
References: <20070510182121.GA4117@ridley.dbaron.org>
	<Pine.LNX.4.62.0902110838000.28232@hixie.dreamhostps.com>
Message-ID: <20090211193625.GA1929@pickering.dbaron.org>

On Wednesday 2009-02-11 08:39 +0000, Ian Hickson wrote:
> On Thu, 10 May 2007, L. David Baron wrote:
> >
> > The interaction of area elements with CSS styling is not defined in HTML 
> > 5.  Since area elements are particularly unusual (in that they appear an 
> > arbitrary number of times, whenever their containing map is linked to by 
> > an img), I think it should be.
> 
> Fixed. Please let me know if the new text is ok:
> 
>    http://www.whatwg.org/specs/web-apps/current-work/#image-maps-0

That text seems ambiguous in the case of values like 'cursor:
inherit' on area elements (and the possibility of future values that
also take values from the parent element).  In particular, the text:
  # has a value explicitly specified (as opposed to inheriting it
  # from the element's parent)
seems self-contradictory regarding 'cursor: inherit'.

It also seems to require (for handling cursor:inherit) that the CSS
implementation expose information about whether the property was
specified on the element.  I don't know of other cases that require
this.

What Gecko does is simply "do selector matching based on the
document tree but then value computation as though the img element
were the parent".  (I think this is a similar concept to what the
XBL2 spec requires in some cases, although I don't remember for sure.)

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/


From lists.webapps at stakface.com  Wed Feb 11 12:14:44 2009
From: lists.webapps at stakface.com (Kartikaya Gupta)
Date: Wed, 11 Feb 2009 20:14:44 +0000
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <162ED70B-388B-4FC1-9130-D796543F8D03@apple.com>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
	<6AACBF67-F82E-432E-9ACC-1376F1902E9E@apple.com>
	<20090211185112.4F94D28085@mail-in11.apple.com>
	<162ED70B-388B-4FC1-9130-D796543F8D03@apple.com>
Message-ID: <20090211201444.A585D14D8CC@looneymail-mx2.g.dreamhost.com>

On Wed, 11 Feb 2009 10:58:00 -0800, Darin Adler <darin at apple.com> wrote:
> 
> On Feb 11, 2009, at 10:51 AM, Kartikaya Gupta wrote:
> 
> > Interesting. What version did you try on? I used Chrome 1.0.154.48  
> > and Safari 3.1 (525.13) on Windows.
> 
> The relevant version is the WebKit version rather than the Safari  
> version. They have separate version numbers.
> 
> I used WebKit/525.27.1 (the version that came with Safari 3.1.1) on  
> Mac OS X and also WebKit tip of tree on Mac OS X.
> 
> I also inspected the code and saw nothing that would create an object  
> in the JavaScript binding for this.
> 

I updated to Safari 3.2 on Windows (which looks it also has WebKit 525.27.1) and you're right, it is now showing "number" instead of "object". I guess this was changed not too long ago. So then my question is: why was it changed? And seeing as Opera, WebKit, and Gecko are in agreement now to return a number rather than a Date in ECMAScript, will the DOM 3 Core spec be updated? Or will this get rolled into Web DOM Core and/or HTML5?

Cheers,
kats


From jens at meiert.com  Wed Feb 11 13:08:36 2009
From: jens at meiert.com (Jens Meiert)
Date: Wed, 11 Feb 2009 22:08:36 +0100
Subject: [whatwg] [html5] Semantic elements and spec complexity
In-Reply-To: <Pine.LNX.4.62.0902100625270.28232@hixie.dreamhostps.com>
References: <412901B0.3070500@annevankesteren.nl>
	<Pine.LNX.4.61.0408281349300.8458@dhalsim.dreamhost.com>
	<4130B594.2000006@annevankesteren.nl>
	<Pine.LNX.4.61.0411091436280.4110@dhalsim.dreamhost.com>
	<689CD652-3320-11D9-8ACF-000A95AD3972@myrealbox.com>
	<41924EDD.7000602@cam.ac.uk>
	<Pine.LNX.4.62.0902100625270.28232@hixie.dreamhostps.com>
Message-ID: <9fbcac550902111308t7bd52198i732d47c358026ed1@mail.gmail.com>

On Tue, Feb 10, 2009 at 10:02 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 11 Nov 2004, Matthew Thomas wrote:
>
> On Wed, 10 Nov 2004, James Graham wrote:

Brilliant. I'm opting out of replies to my 2004 mails though ;)

-- 
Jens Meiert
http://meiert.com/en/


From dgerard at gmail.com  Wed Feb 11 13:34:50 2009
From: dgerard at gmail.com (David Gerard)
Date: Wed, 11 Feb 2009 21:34:50 +0000
Subject: [whatwg] Fwd:  [html5] Semantic elements and spec complexity
In-Reply-To: <fbad4e140902111334m315fdb1cr48e2d71c03e6703c@mail.gmail.com>
References: <412901B0.3070500@annevankesteren.nl>
	<Pine.LNX.4.61.0408281349300.8458@dhalsim.dreamhost.com>
	<4130B594.2000006@annevankesteren.nl>
	<Pine.LNX.4.61.0411091436280.4110@dhalsim.dreamhost.com>
	<689CD652-3320-11D9-8ACF-000A95AD3972@myrealbox.com>
	<41924EDD.7000602@cam.ac.uk>
	<Pine.LNX.4.62.0902100625270.28232@hixie.dreamhostps.com>
	<fbad4e140902111334m315fdb1cr48e2d71c03e6703c@mail.gmail.com>
Message-ID: <fbad4e140902111334v118cac83ya495fdfa7a892785@mail.gmail.com>

(to list as well)


---------- Forwarded message ----------
From: David Gerard <dgerard at gmail.com>
Date: 2009/2/11
Subject: Re: [whatwg] [html5] Semantic elements and spec complexity
To: Ian Hickson <ian at hixie.ch>


2009/2/10 Ian Hickson <ian at hixie.ch>:
> On Thu, 11 Nov 2004, Matthew Thomas wrote:

>> 1.  Most authors Just Don't Care about semantic markup. They'll only use
>>     it if it's the easiest way of getting the visual effect or behavior
>>     they want in their own favorite browser, or if they can use it to
>>     game search engines. (That's why authors use <ul> and <li>, for
>>     example, but not <address>.)

> I don't know if the thrust of this argument is true, but I am pretty sure
> the parenthetical isn't. If authors don't use <address> I think it's
> because of a variety of reasons including its poor name, and its lack of
> particularly useful purpose.
> I think there is a wide range of authoring styles, ranging from the author
> who really hasn't any idea that there is such a thing as semantics, and
> just thinks visually, to the author who just wants to get stuff done but
> understands that there are elements for specific purposes like lists, to
> the author who has bought the semantics religion but doesn't really
> understand it, leading to all kinds of "innovative" (and wrong) uses of
> HTML's less well known elements.


This debate has come up on the Wikipedia tech lists concerning markup.

HTML was intended to be a markup language usable by humans. However,
the humans it was written for just happened to be Ph.D nuclear
physicists. Lesser humans have a propensity to write tag soup.
However, in human-writing circumstances, this is a feature rather than
a bug - if it weren't, wikitext would be perfectly-formed XML rather
than tag soup.

So the tricky one is to write a language definition that does
something meaningful with tag soup. Because "tag soup" is what human
languages are too, and they're learned in a similar fashion (try stuff
and see if it works).

Think of tag-soupness as a feature, not a bug. Shudder in horror at
what this implies.


- d.


From dgerard at gmail.com  Wed Feb 11 13:36:25 2009
From: dgerard at gmail.com (David Gerard)
Date: Wed, 11 Feb 2009 21:36:25 +0000
Subject: [whatwg] [html5] Semantic elements and spec complexity
In-Reply-To: <fbad4e140902111334v118cac83ya495fdfa7a892785@mail.gmail.com>
References: <412901B0.3070500@annevankesteren.nl>
	<Pine.LNX.4.61.0408281349300.8458@dhalsim.dreamhost.com>
	<4130B594.2000006@annevankesteren.nl>
	<Pine.LNX.4.61.0411091436280.4110@dhalsim.dreamhost.com>
	<689CD652-3320-11D9-8ACF-000A95AD3972@myrealbox.com>
	<41924EDD.7000602@cam.ac.uk>
	<Pine.LNX.4.62.0902100625270.28232@hixie.dreamhostps.com>
	<fbad4e140902111334m315fdb1cr48e2d71c03e6703c@mail.gmail.com>
	<fbad4e140902111334v118cac83ya495fdfa7a892785@mail.gmail.com>
Message-ID: <fbad4e140902111336w15be72l5fffa88ecbb8fca@mail.gmail.com>

2009/2/11 David Gerard <dgerard at gmail.com>:

> So the tricky one is to write a language definition that does
> something meaningful with tag soup. Because "tag soup" is what human
> languages are too, and they're learned in a similar fashion (try stuff
> and see if it works).


Oh - and the way MediaWiki (the engine Wikipedia uses) deals with this
is: there *is* no language definition - it's a series of PHP regular
expressions. The parser is the actual definition of wikitext. This is
horrifying in both big and small detail, of course. Also, the language
is provably impossible to put into EBNF form. Argh.


- d.


From ian at hixie.ch  Wed Feb 11 13:37:46 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 21:37:46 +0000 (UTC)
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <7c2a12e20902110337u626c67b7p8e1a2b4aa63ec67a@mail.gmail.com>
References: <Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com> 
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
	<498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
	<20090209142419.GA2461@stripey.com>
	<65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>
	<Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>
	<7c2a12e20902110337u626c67b7p8e1a2b4aa63ec67a@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902112136010.952@hixie.dreamhostps.com>

On Wed, 11 Feb 2009, Aryeh Gregor wrote:
> 
> You could say that not only should authors never set the background 
> color without setting the foreground color, they should also never set 
> the background color without setting the *link* color.

Yeah, that's what I meant.


> But this still doesn't help if the UA (or a user stylesheet) uses
> 
> span { color: green; }

Such a user would be to blame for again not setting the colour and 
background (and link colour for links in the <span>) together.


> I don't think there's any way around this.  If a UA sets unexpected 
> style rules, it *will* break some sites.  I imagine that the response to 
> this is that while this may be so, it's possible that in some cases it 
> will be a tradeoff against platform integration or something, and so it 
> should still be up to the implementers to decide whether it's a good 
> tradeoff in their case.  The expectation would be that for conventional 
> browsers, it won't be.  This is pretty much just the definition of 
> "should" in RFC2119.

I mostly agree, except that I think the current spec text (using "expected 
to" rather than "should") more accurately represents what we want here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Feb 11 13:41:26 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 21:41:26 +0000 (UTC)
Subject: [whatwg] Fwd:  [html5] Semantic elements and spec complexity
In-Reply-To: <fbad4e140902111334v118cac83ya495fdfa7a892785@mail.gmail.com>
References: <412901B0.3070500@annevankesteren.nl>
	<Pine.LNX.4.61.0408281349300.8458@dhalsim.dreamhost.com>
	<4130B594.2000006@annevankesteren.nl>
	<Pine.LNX.4.61.0411091436280.4110@dhalsim.dreamhost.com>
	<689CD652-3320-11D9-8ACF-000A95AD3972@myrealbox.com>
	<41924EDD.7000602@cam.ac.uk>
	<Pine.LNX.4.62.0902100625270.28232@hixie.dreamhostps.com>
	<fbad4e140902111334m315fdb1cr48e2d71c03e6703c@mail.gmail.com>
	<fbad4e140902111334v118cac83ya495fdfa7a892785@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902112140510.952@hixie.dreamhostps.com>

On Wed, 11 Feb 2009, David Gerard wrote:
> 
> Think of tag-soupness as a feature, not a bug. Shudder in horror at what 
> this implies.

I don't think that's a particularly controversial position here. People in 
other mailing lists involved in the development of HTML5 might disagree. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From fantasai.lists at inkedblade.net  Wed Feb 11 14:43:08 2009
From: fantasai.lists at inkedblade.net (fantasai)
Date: Wed, 11 Feb 2009 14:43:08 -0800
Subject: [whatwg] Selectors Tests and :enabled
In-Reply-To: <Pine.LNX.4.62.0902110824030.28232@hixie.dreamhostps.com>
References: <49071641.4000609@lachy.id.au> <4908C0BD.8090108@inkedblade.net>
	<4908D475.5060701@lachy.id.au>
	<Pine.LNX.4.62.0902110824030.28232@hixie.dreamhostps.com>
Message-ID: <4993547C.5010701@inkedblade.net>

Ian Hickson wrote in http://lists.w3.org/Archives/Public/www-style/2009Feb/0328.html :
> On Wed, 29 Oct 2008, Lachlan Hunt wrote:
>> fantasai wrote:
>>> Lachlan Hunt wrote:
>>>> http://lachy.id.au/dev/css/tests/selectors/pseudo-classes/ui/
>>> Interesting. I'm not convinced that :enabled and :disabled shouldn't match
>>> <input type="hidden">. Konqueror and Mozilla both make them match, so I'd
>>> like to check with the CSSWG if that's really the interpretation we want
>>> before deciding whether to accept your tests. 
>> Opera currently also makes them match, but WebKit doesn't.  However, the
>> Selectors spec states that:
>>
>>   Most elements will be neither enabled nor disabled. An element is
>>   enabled if the user can either activate it or transfer the focus to
>>   it. An element is disabled if it could be enabled, but the user cannot
>>   presently activate it or transfer focus to it.
>>
>> Since a hidden input cannot be activated or have focus transferred to it, my
>> understanding is that they shouldn't match, which makes WebKit's behaviour
>> correct, and Opera, Firefox and Konqueror all incorrect.  But if the intention
>> is for these pseudo classes to match hidden inputs, then please fix the spec.
>>
>>> AFAICT WF2 requires them to match, but Selectors' wording implies that they
>>> don't.
>> The Web Forms 2 spec is obsolete now that forms have been integrated into
>> HTML5.
> 
> HTML5 now says :enabled never matches type=hidden. (And :disabled doesn't 
> either, since you can't disable an <input type=hidden>.)

Given the state of current implementations and the fact that hidden input
elements do have distinct enabled and disabled states, I don't understand
the reasoning behind this change.
   http://twitter.com/WHATWG/status/1198455588

On a related note, the HTML5 spec currently defines :enabled to match
<a>, <area>, and <link> elements, as well as any other elements that are
focusable--conflicting with the Selectors spec, which defines :enabled
to only apply to elements that have a corresponding disabled state.
   http://dev.w3.org/csswg/selectors3/#UIstates
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#matching-html-elements-using-selectors

One of these specs needs to change. If you think it should be Selectors,
please explain your reasoning and why you believe it is important enough
to force implementations conforming to the Selectors definition of
:enabled (of which we have at least three) to change.

~fantasai


From darin at apple.com  Wed Feb 11 15:03:01 2009
From: darin at apple.com (Darin Adler)
Date: Wed, 11 Feb 2009 15:03:01 -0800
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <20090211201444.8E03428052@mail-in11.apple.com>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
	<6AACBF67-F82E-432E-9ACC-1376F1902E9E@apple.com>
	<20090211185112.4F94D28085@mail-in11.apple.com>
	<162ED70B-388B-4FC1-9130-D796543F8D03@apple.com>
	<20090211201444.8E03428052@mail-in11.apple.com>
Message-ID: <8F614BCE-F819-4466-B195-7CE7CE540030@apple.com>

On Feb 11, 2009, at 12:14 PM, Kartikaya Gupta wrote:

> I updated to Safari 3.2 on Windows (which looks it also has WebKit  
> 525.27.1) and you're right, it is now showing "number" instead of  
> "object". I guess this was changed not too long ago. So then my  
> question is: why was it changed?

No, this was not changed.

I don't understand why you were getting that strange result, but  
WebKit has always shown "number" for this. I went back to old  
versions, including digging out a copy of Safari 2 and every version I  
tested yields a number. There was never any code that attempted to  
return anything except a number.

More to the point, there's also a false premise in the specification's  
claim that this should be a Date. The Date class in JavaScript boils  
down to a double for its internal representation; I believe that's by  
design and not just a detail of the WebKit implementation. So the  
claim that a number, also a double, can't handle the entire range of  
DOMTimestamp, but the Date class can is probably incorrect. Maybe  
someone can give a specific example with details of how this would go  
wrong ? I don?t think there is any such example.

     -- Darin



From ian at hixie.ch  Wed Feb 11 15:42:57 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 11 Feb 2009 23:42:57 +0000 (UTC)
Subject: [whatwg] Selectors Tests and :enabled
In-Reply-To: <4993547C.5010701@inkedblade.net>
References: <49071641.4000609@lachy.id.au> <4908C0BD.8090108@inkedblade.net>
	<4908D475.5060701@lachy.id.au>
	<Pine.LNX.4.62.0902110824030.28232@hixie.dreamhostps.com>
	<4993547C.5010701@inkedblade.net>
Message-ID: <Pine.LNX.4.62.0902112340160.952@hixie.dreamhostps.com>

On Wed, 11 Feb 2009, fantasai wrote:
> 
> Given the state of current implementations and the fact that hidden input
> elements do have distinct enabled and disabled states, I don't understand
> the reasoning behind this change.
>   http://twitter.com/WHATWG/status/1198455588

The idea was to match Selectors.


> On a related note, the HTML5 spec currently defines :enabled to match
> <a>, <area>, and <link> elements, as well as any other elements that are
> focusable--conflicting with the Selectors spec, which defines :enabled
> to only apply to elements that have a corresponding disabled state.

The spec text I read said "An element is enabled if the user can either 
activate it or transfer the focus to it. An element is disabled if it 
could be enabled, but the user cannot presently activate it or transfer 
focus to it.", which is what I tried to follow:

   http://www.w3.org/TR/css3-selectors/#UIstates


>  http://dev.w3.org/csswg/selectors3/#UIstates

I see this has now changed. I will update HTML5 in due course to match 
the new text in Selectors.

(I'll also update my spec index to point to the dev.w3.org link instead of 
the /TR/ page so that I don't make this mistake again.)

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Feb 11 17:23:13 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Feb 2009 01:23:13 +0000 (UTC)
Subject: [whatwg] When do scripts execute? (4.3.1)
In-Reply-To: <63df84f0901151509w5a164c06k7b2dc335db82ed38@mail.gmail.com>
References: <20090115154846.C88A714D983@looneymail-mx2.g.dreamhost.com>
	<496F641A.6030002@mit.edu>
	<63df84f0901151509w5a164c06k7b2dc335db82ed38@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902120112310.28232@hixie.dreamhostps.com>

On Thu, 15 Jan 2009, Kartikaya Gupta wrote:
>
> I have a question about when scripts execute. From my reading of section 
> 4.3.1 it seems like if script elements are created and added to the DOM 
> via DOM operations, then they should NOT be marked as parser-inserted, 
> and should get run immediately (assuming no defer/async stuff). However, 
> a page that I constructed to test this (below) fails in FF, Opera, and 
> Safari (didn't test IE). Am I misreading the spec, or does it not 
> accurately reflect current behavior? I found [1] after poking through 
> the archives a bit, and it's somewhat related, but doesn't address this 
> issue directly.
> 
> <div id="r">NOTRUN</div>
> <script type="text/javascript">
>  var sn = document.createElement('script');
>  sn.setAttribute( 'type', 'text/javascript' );
>  sn.appendChild( document.createTextNode( 'document.getElementById("r").firstChild.data = "PASS";' ) );
>  document.body.appendChild( sn );        // this runs the script and sets r's text to PASS (verifiable by alert)
> 
>  sn = document.createElement( 'script' );
>  sn.setAttribute( 'type', 'text/javascript' );
>  document.body.appendChild( sn );        // this *should* run an empty script block and do nothing
>  // the next line should have no effect since the script already ran
>  sn.appendChild( document.createTextNode( 'document.getElementById("r").firstChild.data = "FAIL";' ) );
>  // here r's text is FAIL. why?
> </script>
> 
> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011561.html

On Thu, 15 Jan 2009, Boris Zbarsky wrote:
> 
> That looks like a bug in the spec to me.  Empty scripts with no @src are 
> not executed when inserted into the DOM, and are executed if they ever 
> become nonempty or have their src set.

On Thu, 15 Jan 2009, Jonas Sicking wrote:
> 
> At least in the mozilla implementation, though would be interested what 
> other implementations do. The reason was that I wanted to support the 
> following usage pattern:
> 
> s = document.createElement('script');
> document.body.appendChild(s);
> s.src = "http://foo/bar";
> 
> Note that in IE, you can set the src attribute any number of times and 
> every time it will download and execute the new script, even when the 
> old src value is the same as the new.

I've updated the spec to work like Boris describes. The browsers aren't 
all exactly the same, but this seems like the most consistent set of 
requirements that matches the most browsers.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Feb 11 18:03:02 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Feb 2009 02:03:02 +0000 (UTC)
Subject: [whatwg] Issues concerning the <base> element and xml:base
In-Reply-To: <49722571.9060107@email.it>
References: <4637D68D.6000300@sicking.cc> <465E0C79.7030608@sicking.cc>
	<Pine.LNX.4.64.0708070248560.9753@dhalsim.dreamhost.com>
	<46C122D8.4000000@sicking.cc>
	<Pine.LNX.4.62.0802130101260.20115@hixie.dreamhostps.com>
	<47C94C35.1000409@sicking.cc>
	<AEDA4554-6737-40C2-88DD-7E932F52AE5B@apple.com>
	<20080302021821.GB22099@ridley.dbaron.org>
	<3A96FD87-E0F8-48EA-8BA3-B7A5B96ED848@apple.com>
	<20080302063125.GA11915@ridley.dbaron.org>
	<4C40D961-FED9-47A5-9833-96E685609CCA@apple.com>
	<op.t7eshxhd64w2qv@annevk-t60.oslo.opera.com>
	<Pine.LNX.4.62.0806060028380.8559@hixie.dreamhostps.com>
	<F2B519BF-A2FD-4AA8-A8A7-3A216315BB77@apple.com>
	<4880020D.2080605@sicking.cc>
	<Pine.LNX.4.62.0901152314100.7181@hixie.dreamhostps.com>
	<496FD34B.9060306@sicking.cc>
	<Pine.LNX.4.62.0901160033010.29785@hixie.dreamhostps.com>
	<496FF48F.4090009@email.it>
	<Pine.LNX.4.62.0901160409471.29785@hixie.dreamhostps.com>
	<49722571.9060107@email.it>
Message-ID: <Pine.LNX.4.62.0902120159440.28232@hixie.dreamhostps.com>

On Fri, 16 Jan 2009, Anne van Kesteren wrote:
> On Fri, 16 Jan 2009 05:15:41 +0100, Ian Hickson <ian at hixie.ch> wrote:
> > For external resource links created with the <link> element, the URL 
> > is resolved when the resource is fetched, which can be delayed if the 
> > resource doesn't apply yet (e.g. because a media query doesn't yet 
> > match). This could lead to situations where different user agents had 
> > compliant behavior, unfortunately, but this is one case where I can't 
> > see how to avoid it without requiring suboptimal behavior.
> 
> You have the same scenario for inline <style> elements that are either 
> in alternate state or are of a medium that currently does not apply to 
> the document. The user agent is not required to parse those CSS blocks 
> directly, I believe.

Right.


On Fri, 16 Jan 2009, Jonas Sicking wrote:
> >>
> >> Out of curiosity, why make exceptions for hyperlinks here and the 
> >> cite attribute here? As opposed to for example images and iframes?
> >
> > Because the "don't do anything special" behavior (not caching the 
> > absolute URL or anything like that) leads to the following scenario:
> >
> >   user hovers over link
> >   UA resolves URL for display
> >   script changes the base URL
> >   user clicks link
> >   UA resolves URL differently for navigation
> >
> > ...leading to the UI not matching what the UA actually does unless the 
> > UI is updated when the base URL changes. It's only a "should" though, 
> > because well, if you want your UI to be out of date, it's not 
> > critical.
> >
> > I can make it a "may" if you think "should" is too strong.
> 
> I don't care much either way. I think I'd prefer it more strongly for 
> the 'cite' attribute.

Well the spec says "If the absolute URL identified by the cite attribute 
is being shown to the user, or if any data derived from that URL is 
affecting the display", which basically means that for most browsers 
there's no issue here, no?


On Sat, 17 Jan 2009, Calogero Alex Baldacchino wrote:
> 
> I understand. Perhaps, if a main (more diffused) behaviour could be 
> isolated, it might be chosen to "normalize" newer UAs behaviours, while 
> possibly breaking fewer existing pages (the same eventually behaving 
> differently in different browsers). However, I guess this might require 
> a convergence between HTML and CSS specifications for this purpose (it 
> might rise an issue on consistence for @import rules, for instance, 
> which are in CSS scope).
> 
> I don't know if it may work something like establishing that a URL, in 
> this case, is resolved any times it is explicitly set (e.g. when the 
> document is parsed and when the "href" value changes), as if the 
> resources were immediately fetched (thus, not being affected by a 
> successive change in a <base>) but not constraining UAs to do so (an 
> inline style element might be treated as an external resource being yet 
> fetched, thus it would be about to associate it with a base URI being 
> valid at the moment the style was created and maintained valid until the 
> style content is explicitely changed). Though, I guess this should be 
> somehow consistent with existing UAs and pages (or, at least, with a 
> significant group).

I don't really follow. if you are proposing a change to the spec, could 
you elaborate on what exactly the change you propose is?

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Feb 11 21:23:09 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Feb 2009 05:23:09 +0000 (UTC)
Subject: [whatwg] Proposed additions to ClientInformation interface
In-Reply-To: <8e61feeb0901162221j7bf3133cqea077a865a2bd299@mail.gmail.com>
References: <8DF933CB-F8F9-42C3-94EF-511FFB9986F3@apple.com> 
	<Pine.LNX.4.62.0807062340270.11215@hixie.dreamhostps.com> 
	<23FC70C5-8CAC-4861-8D59-AF76A8649CBD@apple.com>
	<200807081843.17071.giecrilj@stegny.2a.pl>
	<Pine.LNX.4.62.0807220219510.11948@hixie.dreamhostps.com>
	<8e61feeb0901162221j7bf3133cqea077a865a2bd299@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902120438500.28232@hixie.dreamhostps.com>

On Sat, 17 Jan 2009, Mark Finkle wrote:
> On Mon, Jul 21, 2008 at 10:10 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 7 Jul 2008, Mark Finkle wrote:
> > >
> > > The only reason I can see for such an API is to get the user's 
> > > permission to use features that _may_ be a bit of a security risk to 
> > > normal webapps. Clipboard, dock badging, local file drag-n-drop, 
> > > even offline cache are some examples.
> >
> > Clipboard, drag and drop, and offline caching are all available to all 
> > applications in HTML5, since the APIs are intended to be designed in a 
> > way that doesn't expose the user to risk that requires user 
> > permission.
> 
> Then why would a button be needed to "activate" standalone mode? What is 
> the actual webapp doing differently? Shouldn't the webapp be acting the 
> exact same? Sounds like it's the UA that would act differently.

In "standalone" mode, a Web application can pretend to be a Web browser, 
tricking the user into thinking they are visiting a site they are not in 
fact visiting, and thus executing a remarkably authentic-looking phishing 
attack. That is why it needs an explicit opt-in.


> > Dock badging could be equally made available safely, IMHO. The main 
> > reason I haven't made dock badging available so far is that it doesn't 
> > really make sense for most environments -- in fact as far as I know 
> > only Mac OS X has this feature.
> 
> Great to know. Prism has code that allows <menu> and <command> elements 
> to be used to add menuitems to the Dock (Trayicon on Windows) menu as 
> well. We could even support something like <menu type="icon">...</menu> 
> for this too. Ignored by UAs that don't support it.

Yes, this is one of the things I'm interested in exploring once <menu> and 
<command> (as specified today) are implemented. (Another is introducing a 
command="" attribute to make it possible to define command state once 
and have UI widgets reflect that state automatically.)


> I am suggesting that an explicit "push to make a standalone app" button 
> isn't needed. Any webapp is already able to run standalone. _If_ there 
> is some reason, for security or code privilege, that an explicit action 
> or confirmation is needed on the part of the user, such confirmation 
> should be enforced at the point of execution, when the user attempts to 
> do something that might be dangerous.

It's unclear how that would work. Confirmations in general are known to 
not work, for instance (users click through anything).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From simonp at opera.com  Wed Feb 11 22:03:22 2009
From: simonp at opera.com (Simon Pieters)
Date: Thu, 12 Feb 2009 07:03:22 +0100
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <20090211201444.A585D14D8CC@looneymail-mx2.g.dreamhost.com>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
	<6AACBF67-F82E-432E-9ACC-1376F1902E9E@apple.com>
	<20090211185112.4F94D28085@mail-in11.apple.com>
	<162ED70B-388B-4FC1-9130-D796543F8D03@apple.com>
	<20090211201444.A585D14D8CC@looneymail-mx2.g.dreamhost.com>
Message-ID: <op.uo75rwo1idj3kv@zcorpandell.linkoping.osa>

On Wed, 11 Feb 2009 21:14:44 +0100, Kartikaya Gupta <lists.webapps at stakface.com> wrote:

> I updated to Safari 3.2 on Windows (which looks it also has WebKit  
> 525.27.1) and you're right, it is now showing "number" instead of  
> "object". I guess this was changed not too long ago. So then my question  
> is: why was it changed? And seeing as Opera, WebKit, and Gecko are in  
> agreement now to return a number rather than a Date in ECMAScript, will  
> the DOM 3 Core spec be updated? Or will this get rolled into Web DOM  
> Core and/or HTML5?

Right now Web DOM Core says:

   A DOMTimeStamp represents a number of milliseconds. 

      typedef unsigned long long DOMTimeStamp;


...and then refers to WebIDL for what that means to ECMAScript.

-- 
Simon Pieters
Opera Software




From ian at hixie.ch  Wed Feb 11 22:38:28 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Feb 2009 06:38:28 +0000 (UTC)
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <49739DBD.4090407@mit.edu>
References: <49739DBD.4090407@mit.edu>
Message-ID: <Pine.LNX.4.62.0902120632030.28232@hixie.dreamhostps.com>

On Sun, 18 Jan 2009, Garrett Smith wrote:
> 
> What do IE6, IE7 and IE8 do?

I only tested IE8 and IE8's IE7 compatibility mode, and I don't recall 
exactly what the results were, but they were taken into account when 
writing the spec here. (In particular, IE doesn't distinguish between the 
form and its .elements array, which doesn't match HTML5 or DOM2 HTML.)


> In all browsers, if the control is referenced as:-
> 
>   document.forms[0].elements.b;
> 
> - the leak does not occur.

In IE, the above and

   document.forms[0].b

...are exactly the same.


> >> What is the reason for introducing the "past names map" behavior to 
> >> the form?
> >
> > Compatibility with a legacy IE bug required (acording to Safari and 
> > Firefox devs) by legacy content.
> 
> If I understand what you're saying, you are taking advice on what IE 
> does from Safari and Firefox devs. Was there a test?

I take advice on what the spec should say from everyone. I test things 
independently also.


> I posted an earlier example "simple-leak-form-input.html" that showed 
> how in IE, removing a control from the document removes the property 
> from a form. This is generally what you want. You don't want the browser 
> to leak form controls. The "past names map" is not even defined as an 
> interface; it's a euphamism for a bug.

Unfortunately, as with many weird behaviors on the Web platform, it is a 
"bug" that is required for compatibility with legacy content.


> > The idea of HTML5 is to make sure that a browser that implements all 
> > of HTML5 is compatible with legacy content. This is one of the things 
> > that legacy content requires, so the spec has to require it too.
> 
> I think I understand this position. HTML5 wants to add new functionality 
> without breaking any existing functionality. That is a good goal, and an 
> important one if it is to be accepted.
> 
> OTOH, the legacy behavior is buggy and inconsistent. It's also been 
> replaced by a much better feature (the elements collection). You've not 
> attempted to refute any of that; on the contrary, I see the spec 
> includes a 'past names map' and since you've not provided any evidence, 
> the "should not be used. It is practical to deprecate it.

I don't really understand what you mean here.

I'm not deprecating anything in HTML5. Things are either allowed or not 
allowed (obsolete). With scripting, I've erred on the side of not 
obsoleting things, since there doesn't seem much point in doing so, 
especially for such minor non-features as this.


> There are plenty of useless/bad things browsers do. For example,
> accessing a named form directly off the document, as
> document.formName, or standardizing the way an identifier matching an
> element ID is resolved to that element.
> 
> <html>
> <body>
> <div id="a">...</div>
> 
> <script>
>   //[1] var a;
>   alert(typeof a);
> </script>
> </body>
> </html>
> 
> Result:
>   elerts "object"
> 
> If [1] is uncommented, results vary between browsers and versions.
> This quirk was a problem not too long ago for the Google Code
> developers. It was filed as a Webkit bug that got "fixed".

HTML5 covers this case, IIRC.


> There are other things that could be standardized, such as quirks mode, 
> String.prototype.anchor(surl), or any number of things that have better 
> alternatives.

Quirks mode is in HTML5. The String prototype is an ECMAScript issue and 
is out of scope here.


> > The idea is to make it so that browsers don't feel forced to add _any_ 
> > non-standard behavior (other than experimental innovations using 
> > vendor- prefixed names and stuff).
> 
> HTML5 does make distinctions for legacy content in some places, but not 
> with this behavior. It would be a good idea to make a clear distinction 
> that accessing form controls directly off the form is legacy content.

Why?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Feb 11 22:55:18 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Feb 2009 06:55:18 +0000 (UTC)
Subject: [whatwg] Script/parser interaction bug?
In-Reply-To: <20090120004348.78E3B828E@looneymail-mx3.g.dreamhost.com>
References: <20090120004348.78E3B828E@looneymail-mx3.g.dreamhost.com>
Message-ID: <Pine.LNX.4.62.0902120645590.28232@hixie.dreamhostps.com>

On Tue, 20 Jan 2009, Kartikaya Gupta wrote:
>
> I have a test case that works in major browsers (FF, Opera, Safari, IE6) 
> but that I don't think would work if the they followed the behavior as 
> currently specified in HTML5. I've put the test case online:
> 
> http://stakface.com/pub/mango/ext7.html
> 
> The assertion "document.getElementById('r').firstChild.data == 'PASS'" 
> is true after the page has loaded, whereas according to the spec I don't 
> think it shouldn't be.
> 
> The steps are roughly as follows:
> - tokenize/treebuild ext7.html until the first closing script tag is found (for the 7a.js script)
> - run the script. this sets 7a.js to be the "pending external script"
> - execute the "pending external script" (7a.js) since it's not a re-entrant invocation of the tree builder
> --- insert the 7b.js line into the input stream
> --- tokenize/treebuild the 7b.js script tag until the </script> for 7b.js is found
> --- run the script. this sets 7b.js to be the "pending external script"
> --- now, since there is a "pending external script" and this is a re-entrant invocation, set the pause flag to true and bail
> --- insert the other stuff in 7a.js into the input stream
> --- since the parser pause flag is set this other stuff does NOT get tokenized/treebuilt yet
> - 7a.js finishes executing, and now we have a new "pending external script", which is 7b.js

I think the parser pause flag gets set to false again here.

> - execute 7b.js
> --- throws
> - continue processing input stream (this now has the contents of the document.write calls from 7a.js, line 2 onwards)
> - tokenize/treebuild the input stream until the </script> that was document.write'd at the bottom of 7a.js is encountered
> - execute the script
> --- insert the div into the input stream
> --- since the parser pause flag is still set the div does NOT get tokenized/treebuilt

Why is it still set?

> --- run the line that sets .firstChild.data to PASS. since the div isn't in the DOM yet, this throws and the script is done
> - unwind back to the treebuilder, which clears the parser pause flag since the script nesting level drops to zero
> - tokenize/treebuild the input stream, which contains the div tag
> - add div with content FAIL to the DOM
> - done
> 
> Here, I think the pause flag needs to get cleared earlier, so that when 
> the div is inserted into the input stream, it gets tokenized and added 
> to the DOM. This would make the behavior consistent with what I'm seeing 
> in major browsers. Thoughts?

Could you reannotate the above but with the script nesting level 
explicitly given at each step?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From dhtmlkitchen at gmail.com  Wed Feb 11 23:43:37 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 11 Feb 2009 23:43:37 -0800
Subject: [whatwg] defer on style, depends
In-Reply-To: <4990F667.5060701@mit.edu>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>
	<Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com>
	<c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>
	<49906AFA.804@mit.edu>
	<c9e12660902091056t10eba8d1i91bcb8f9bda3a528@mail.gmail.com>
	<49908A11.6070905@mit.edu>
	<c9e12660902091815q3a659cf6q592ab7844f7b179f@mail.gmail.com>
	<4990F667.5060701@mit.edu>
Message-ID: <c9e12660902112343q33aeac40i5c791ae5d81760a6@mail.gmail.com>

On Mon, Feb 9, 2009 at 7:37 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Garrett Smith wrote:
>>
>> In general, I want better declarative control over loading external
>> resources. The solution(s) should not cause compatibility problems
>> with existing browsers (because I have to support IE6 and Firefox 2).
>
> Honestly, by the time anything we're discussing now will be shipping in a
> browser Firefox 2 marketshare should be nonexistent.  I can't speak for IE6.
>

I'm optimistic. We can make it so authors can declare that (a)
script/s will not wait for (a) stylesheet? Or declare that a script
will wait for a particular stylesheet (which is something that happens
already).

>> I want the browser to be able to load and run a script without being
>> in the position of trying to determine if it should wait for
>> stylesheet data to complete.
>
> As in you don't want the browser to make this determination, right? That is,
> you know that your script doesn't depend on any style data and you want the
> browser to just run it?
>

In one case, yes.

> I would be fine with a way to flag scripts with that information, though
> there is a catch-22: if you flag such a script and it DOES depend on style
> information, then existing UAs will get it "right" and any UA implementing
> the new spec will get it "wrong".
>

If the page does what it is designed to do, and that the design is
flawed, the page would be broken by design. Designing things to be
broken would be "wrong".

> Of course the same is true for the "flag-the-stylesheet" proposal...
>
>> In browsers that do support defer, the script would run *after* the
>> document parsed, and that would occur after the stylesheet loaded.
>
> I'm not sure why this is a performance problem, per se.
>
>>>> 2) want to load stylesheets later, (infoPanel example)
>>>
>>> Not sure what this example is, or why this is insufficienty served by,
>>> say,
>>> putting the <link> at the end of the HTML (assuming HTML allowed that, of
>>> course).
>>
>> Are you proposing HTML allow that?
>
> That's one possible solution to the issue of starting stylesheet loads as
> late as possible, yes.  It's not a great one a priori, but has the benefit
> of good compat with existing UAs (which you said was a priority for you).
>

Not that I think you are wrong, but that statement ought to be backed
up by some tests.

>> The script could declare whether it needs such resource by its
>> "depends=" attribute. However, browsers today delay (some) scripts
>> from running. Scripts depend on stylesheets; content depends on
>> scripts and stylesheets. Content can contain more scripts. Omitting
>> depends for scripts could not possibly solve the problem for browsers
>> today (because they already depend on stylesheets).
>
> Honestly, I don't think anything would solve the problem for browsers
> _today_.
>

No, just observing that the problem could have been avoided with a
"depends=" attribute, if only such attribute had existed c2000, and
having scripts wait only when depends is set. I like this design.

>> An "independent" attribute on a link says that a browser does not need
>> to wait for that resource to finish loading before it loads other
>> resources (like loading a script). When the parser parses that
>> "independent" attribute, it sets a flag for the browser go ahead and
>> download and run any subsequent script.
>
> That doesn't work for today's browsers, though, just like flagging the
> script doesn't.  Or am I missing something?
>

You got it. It doesn't work for today's browsers. However, it isn't
guaranteed *not* to work by any standard. In fact, browsers behave
differently on the matter. Could this new feature result in breaking
code in older browsers?

Those browsers would load and apply the stylesheet in series. That
would be slower.

A race condition is where the script might run before the sheet loaded.

Developers who don't know that shouldn't use that feature.

The "sad path" -- what can happen when a developer misuses "independent":
Case 1: Developer tests in the browser that supports "independent".
The script runs before the stylesheet loads in browsers that support
independent. The result of the race condition is what the developer
wants. The opposite effect happens in older browser.

Case 2: The author uses "independent" and only tests in browsers that
do not support that feature. When loaded in a newer browser that does
support "independent", the script loads before the stylesheet and the
page does not work as designed.

The problems in case 1 or case 2 could happen today. Browsers today
are inconsistent with waiting for stylesheets to download (try any of
the examples I have provided in Opera, Safari, Firefox, IE).

Developers today blame the browser, or possibly the script when "it
doesn't work".

The happy path:
The "defer" on link and "depends" on script work together. The link is
deferred, then loaded when the script loads.

>> A "nodepends" type attribute on a script would work, too. I like that
>> idea, though it does mean the browser has to do some lookahead (then
>> again, apparently they already do).
>
> What sort of lookahead?  Gecko, for example, just keeps parsing right past a
> stylesheet load.  The only thing we stop the parser for is <script>s,
> because those can do document.write.  And even then, the speculative parser
> continues doing loads past that point.
>
> All that style sheets hold up is the script running, not the script loading
> (in Gecko).  If the script were marked as "doesn't have to wait for
> stylesheets", we could just run it as soon as it loads.
>

You say that stylesheets do not block script loading. That may be true
of "Shiretoko" 1.9.1, however, that is not what I see for Firefox 3.0.
The example I posted shows that stylesheets hold up body content from
rendering. If that content contains a script tag, the script will
*not* load *or* run.

The following example shows this to be true:
http://dhtmlkitchen.com/jstest/block/link-external.html

Here is data taken from Live HTTP Headers.
+---------------------+-------------------------------+
| req                 + HTTP date                     |
----------------------+-------------------------------+
| link-external.html  | Tue, 10 Feb 2009 07:01:13 GMT |
| example.js?top      | Tue, 10 Feb 2009 07:01:13 GMT |
| delay.jsp?ct=text...| Tue, 10 Feb 2009 07:01:13 GMT |
| example.js?bottom   | Tue, 10 Feb 2009 07:01:22 GMT |
+-----------------------------------------------------+

The last request, example.js?bottom exists before the closing body tag.
The HTTP Date of the last request is 8 seconds after the date of delay.jsp.

The only explanation I have for this behavior is that the browser is
waiting for the stylesheet to complete before it requests the script
in the body. That is why it would be better for performance to have
that script prefetched, and prefetching could not be achieved by
placing it in the body.

In Firebug, I see similar results.

Shiretoko 1.9.1 is a different story.

Results using "HTTP Scoop":
+---------------------+-------------------------------+
| req                 + HTTP date                     |
----------------------+-------------------------------+
| link-external.html  | Tue, 10 Feb 2009 19:31:09 GMT |
| example.js?top      | Tue, 10 Feb 2009 07:01:09 GMT |
| delay.jsp?ct=text...| Tue, 10 Feb 2009 07:01:09 GMT |
| example.js?bottom   | Tue, 10 Feb 2009 07:01:09 GMT |
+-----------------------------------------------------+


>>> That's exactly what Gecko does in this case, for what it's worth.  It
>>> will
>>> load the script in parallel, but won't _execute_ the script until the
>>> non-alternate stylesheet has loaded.
>>
>> For a script in the head, that is what Gecko and Webkit will do.
>
> What I said was true for all scripts.  We do not differentiate between
> content in <head> and content in <body> in this regard.
>

In Shiretoko 3.1, true, but in Firefox 3.1, the bottom script is not
loaded. I speculate perhaps because content is not loaded and the
script in the body is treated as content (as are IMG).

http://localhost/jstest/block/link-img.html

>> However, external resources such as SCRIPT or IMG that appear in the
>> BODY will not get requested by the browser until the page content
>> renders.
>
> You mean until all the HTML before the tag has been parsed?  Or something
> else?  There's no dependency between script loading+execution and page
> rendering, in Gecko.  Heck, you can run scripts in a display:none iframe,
> with no rendering in sight.
>

By "all the HTML before the tag has been parsed," I think you mean,
all the HTML before the tag for that IMG or SCRIPT resource. Right? If
I understand you correctly, you are asking me if the resource for that
tag would not load until all the HTML prior has been parsed. Is this
right? Next you're saying that visual display is not correlated to
script loading or script execution. I'm not sure how this is related.
I think I am misunderstanding you.

>> In both cases (head script or body script), the browser will not
>> execute the script until the stylesheet is downloaded. It won't render
>> content that occurs after the script until the script is executed.
>
> That's correct, yes.
>

In Shiretoko, a script, even a deferred script, will not run until the
stylesheet is loaded.

http://dhtmlkitchen.com/jstest/block/link-body-defer-bottom.html
contentLoaded: 5087
onloadFired: 5089
headEnd: 5086

In Shiretoko, that deferred script runs after 5 seconds. That's just
after the stylesheet loads.


>> So what we have here is a daisy chain. Content depends on Script
>> depends on Style. That is very crude order of affairs and offers the
>> developer little control over load order.
>
> Yes, agreed.
>

Can we make an improvement on that, or to make that improvement
configurable to the page author?

>> to fulfill example 2, I would defer the stylesheet, and declare the
>> script at the end depends on it. Before that script could run, the
>> stylesheet would need to be loaded. Since the linked stylesheet is
>> deferred, the body content would render and not be blocked by the
>> linked stylesheet loading.
>
> Ah, that is one thing that Gecko does do: we don't start _layout_ (as
> opposed to parsing) until all the stylesheets in <head> have loaded.
>

For Firefox 3.0, IMG and SCRIPT that are part of the body are fetched
around this time. They are not fetched prior. Why not?

> You can get around this trivially by putting a stylesheet as the first thing
> in <body>; that stylesheet won't block rendering in Gecko 1.9. You get a
> performance hit when the sheet loads, of course, because of the ensuing
> restyle, but you might be ok with that (I presume you are given that you
> want to load the stylesheet after the content has been rendered).
>
> In fact, if you use a <script defer> after the sheet and a sheet at body
> start you'll get the behavior you want in Gecko 1.9.
>

In that case, the link would not block layout. See Example:
http://dhtmlkitchen.com/jstest/block/link-body.html

but the script script would be block subsequent layout for browsers
that do not support defer. Example:
http://dhtmlkitchen.com/jstest/block/link-body-defer.html

If the script is deferred and moved to the very end of the body:-
http://dhtmlkitchen.com/jstest/block/link-body-defer-bottom.html

- the content is displayed, the IMG is loaded and rendered, but the
script is not run until *after* the delayed stylesheet runs.

This would have the dependency effect I wanted (my "example 2"), in Firefox 3.1.

I see a very similar time response effect when moving the deferred
script up to the head, keeping the link in the body. Example:
http://dhtmlkitchen.com/jstest/block/link-defer-top.html

In "Shiretoko" 1.9.1b3pre, a deferred script waits for all stylesheets
to load before running. However, this is not guaranteed behavior in
any standard. It is not what happens in browsers that do not support
defer. Placing scripts before stylesheets and adding defer is not
practical for web compatibility. It would result in poor performance
in browsers that do not support defer and result in divergent
behavior, as mentioned earlier.

> Again, I doubt we can come up with any declarative solution that would work
> with UAs that don't implement defer already....
>
>> Question: When the stylesheet is eventually applied, could the reflow
>> be optimized for performance?
>
> Not easily, no.  Or rather, the reflow already is; the style data
> recomputation is the hard part.
>

What would make it easier? I'd really like to know how to design my
pages so that they are faster and more responsive.

Would it be too outlandish for the link have a "scope" attribute? The
scope could be a selector for a script or element.

>> A deferred a stylesheet would load after the page loads
>
> Note that this is not the behavior deferred scripts have, by the way, at
> least in Gecko.  They load eagerly, but execute lazily...
>

One difference between a script and linked stylesheet is that script
element does not have content that can be accessed by the DOM.

A deferred stylesheet being requested by the browser would not be a
problem. Mozilla already makes predictive fetches for links. However,
if a deferred stylesheet is fetched during loading, should that
stylesheet (and rules.length, etc) be accessible via script in that
time? Should the deferred link fire a load event after the request
completes?

I am interested to hear what you have to say about this.

> -Boris
>

Garrett


From timeless at gmail.com  Thu Feb 12 01:13:51 2009
From: timeless at gmail.com (timeless)
Date: Thu, 12 Feb 2009 11:13:51 +0200
Subject: [whatwg] Author control over media preloading/buffering
In-Reply-To: <11e306600902102020w785ea140v48e21304b96da8ef@mail.gmail.com>
References: <11e306600902102020w785ea140v48e21304b96da8ef@mail.gmail.com>
Message-ID: <26b395e60902120113h6b87b58dva9707d843009378e@mail.gmail.com>

2009/2/11 Robert O'Callahan <robert at ocallahan.org>:
> So, how about adding an "autobuffer" attribute, which instructs the browser that the user
> will probably play the video and as much data as possible should be pre-downloaded?

> By default (when the attribute is not present) the browser would be expected to pause
> the download after reaching HAVE_CURRENT_DATA if the media element is paused and not 'autoplay'.

if i'm a mobile browser vendor (and I am), and if I expect to use
Bluetooth to talk to a cell phone which has high bandwidth costs (and
if you're using an n800/n810 tethered to a phone in Canada, this is
true), then, i'm not sure I really want web pages to specify things
quite like this.

If we're going to suggest something like this, i'd prefer it to be
something like flex=

bufferpriority="1", bufferpriority="2", which establish a sort and
inform the browser which videos are most important, and the browser
can then choose to collect as many of them as it feels comfortable
collecting, possibly to the point that having played the highest
priority, it proceeds to buffer the next highest priority video. If
there are two things w/ bufferpriority="2", then the browser is free
to treat them equally, but having already played one, it would then
favor the other.

There should be a note indicating that browsers are likely to discount
priority if there are too many things at a given level to buffer
(equivalent to having a box set where 5 children have flex=200).


From ian at hixie.ch  Thu Feb 12 02:36:14 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 12 Feb 2009 10:36:14 +0000 (UTC)
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com>
	<B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF>
	<d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com>


The discussion on spellcheck="" focused on two ideas; using spellcheck="" 
mostly as specced here:

   http://damowmow.com/playground/spellcheck.txt

...and doing something with lang="". The idea of using lang="" had 
problems that were pointed out by several people, most notably, the issue 
that the user's language doesn't always match the site's. I think this 
makes it inappropriate for this use.

I have added spellcheck="" to the spec.

If there's anything in the feedback that I missed, please let me know. I 
read every e-mail but there didn't seem to be anything specific that I 
should comment on.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From giecrilj at stegny.2a.pl  Thu Feb 12 04:24:47 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Thu, 12 Feb 2009 13:24:47 +0100
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com><B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF><d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com>
	<Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com>
Message-ID: <FE0565975932454CA24529DB469F2CAD@POCZTOWIEC>

Regarding http://html5.org/tools/web-apps-tracker?from=2800&to=2801, my
requests:

1. Change the literals "true"/"false" to "on"/"off", leaving the DOM values
Boolean.
2. Check the spelling of the passage ("asits"!) :0)
3. Say that the default behavior for BODY is "on" and the default behavior
for INPUT[type=text] is "off".
4. (I understand that it is implicit that this "SHOULD indicate" does not
make tiny clients that do not have the resources non-compliant?)

Stretching it a bit, a user's language always matches the site's, otherwise
the user would not be able to submit to the site anything that makes sense,
except when the site is a gateway for submissions to an uninvolved third
party, in which case said submissions should be tagged with the language of
submission anyway (IMHO).

Best regards,
Chris







From bil at corry.biz  Thu Feb 12 05:47:41 2009
From: bil at corry.biz (Bil Corry)
Date: Thu, 12 Feb 2009 07:47:41 -0600
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <FE0565975932454CA24529DB469F2CAD@POCZTOWIEC>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com><B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF><d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com>	<Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com>
	<FE0565975932454CA24529DB469F2CAD@POCZTOWIEC>
Message-ID: <4994287D.5010204@corry.biz>

Kristof Zelechovski wrote on 2/12/2009 6:24 AM: 
> Stretching it a bit, a user's language always matches the site's, 
> otherwise the user would not be able to submit to the site anything 
> that makes sense, except when the site is a gateway for submissions 
> to an uninvolved third party in which case said submissions should be
> tagged with the language of submission anyway (IMHO).

Let me give you an example where this isn't true.  I'm in the United States and I do contract work for a company in Germany.  At the German company, they have an internal bug tracker for their intranet applications.  Usually the bug descriptions are written in German, except mine, which are in English.  So they will submit bugs in both German and in English, depending on who is taking care of the issue.

How do you envision the UA will determine which language the user is writing in?  And what happens when the user submits both German AND English, for two audiences?


- Bil



From giecrilj at stegny.2a.pl  Thu Feb 12 05:57:16 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Thu, 12 Feb 2009 14:57:16 +0100
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <4994287D.5010204@corry.biz>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com><B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF><d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com>	<Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com><FE0565975932454CA24529DB469F2CAD@POCZTOWIEC>
	<4994287D.5010204@corry.biz>
Message-ID: <4DE4A6C483D846959447EC485B0E61F8@POCZTOWIEC>

The server has two ways of knowing the user's preferred language: the user's
preferences and the browser settings, in that order.
Submitting in two languages usually needs two controls, one for English and
one for German, with appropriate markup.  The server must be prepared to
handle this use case.
HTH,
Chris






From Simetrical+w3c at gmail.com  Thu Feb 12 06:47:41 2009
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 12 Feb 2009 09:47:41 -0500
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <4DE4A6C483D846959447EC485B0E61F8@POCZTOWIEC>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com>
	<B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF>
	<d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com>
	<Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com>
	<FE0565975932454CA24529DB469F2CAD@POCZTOWIEC>
	<4994287D.5010204@corry.biz>
	<4DE4A6C483D846959447EC485B0E61F8@POCZTOWIEC>
Message-ID: <7c2a12e20902120647o767beef5u7b7bbbbb6660b975@mail.gmail.com>

On Thu, Feb 12, 2009 at 8:57 AM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> The server has two ways of knowing the user's preferred language: the user's
> preferences and the browser settings, in that order.

Both of which are often wrong.  Users may be multilingual, and
multiple users may use the same computer.  On the forum I administer,
I post almost exclusively in English.  However, sometimes I find
occasion to write a post partly or wholly in Hebrew.  How is the site
supposed to know when I'll decide to do that before I even start
typing the post?  How can the site ever be sure what language the user
will type until he actually starts typing?

The server might be able to make an educated guess as to what language
will be entered, but so can the browser.  And the browser is in a
*much* better position to check that guess, because it has access in
real time to the actual text the user is typing, plus the user
interface language, and -- of course -- any lang= or xml:lang=
attributes specified in the HTML.  Ergo, the logic should be left up
to the browser.

> Submitting in two languages usually needs two controls, one for English and
> one for German, with appropriate markup.  The server must be prepared to
> handle this use case.

I don't understand what you mean here.


From giecrilj at stegny.2a.pl  Thu Feb 12 07:05:14 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Thu, 12 Feb 2009 16:05:14 +0100
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <7c2a12e20902120647o767beef5u7b7bbbbb6660b975@mail.gmail.com>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com><B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF><d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com><Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com><FE0565975932454CA24529DB469F2CAD@POCZTOWIEC><4994287D.5010204@corry.biz><4DE4A6C483D846959447EC485B0E61F8@POCZTOWIEC>
	<7c2a12e20902120647o767beef5u7b7bbbbb6660b975@mail.gmail.com>
Message-ID: <3729213D4D0B4544AC8D4A5935431ACC@POCZTOWIEC>

The language attribute can be changed at run time if needed.  It requires an
additional event that can be called "langmismatch".  Of course, a more
traditional selector is also a solution.  If the site is primary English,
with Hebrew fragments here and there, it is not much harm that the fragments
are considered spelling errors (although, in the case of English/Hebrew
bilingualism, it is unlikely because the character set is different).
In short, the user agent is allowed to use whatever AI it is equipped with.

Markup for German AND English submissions at the same time, as per your
request:
<LABEL LANG="de" >Inhalt: <TEXTAREA NAME=INHALT ></TEXTAREA ></LABEL >
<LABEL LANG="de" >Contents: <TEXTAREA NAME=CONTENTS ></TEXTAREA ></LABEL >

HTH,
Chris





From giecrilj at stegny.2a.pl  Thu Feb 12 07:07:33 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Thu, 12 Feb 2009 16:07:33 +0100
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <7c2a12e20902120647o767beef5u7b7bbbbb6660b975@mail.gmail.com>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com><B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF><d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com><Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com><FE0565975932454CA24529DB469F2CAD@POCZTOWIEC><4994287D.5010204@corry.biz><4DE4A6C483D846959447EC485B0E61F8@POCZTOWIEC>
	<7c2a12e20902120647o767beef5u7b7bbbbb6660b975@mail.gmail.com>
Message-ID: <AA7652FCE5F345D8A69CDF6D4A41A88E@POCZTOWIEC>

The language attribute can be changed at run time if needed.  It requires an
additional event that can be called "langmismatch".  Of course, a more
traditional selector is also a solution.  If the site is primary English,
with Hebrew fragments here and there, it is not much harm that the fragments
are considered spelling errors (although, in the case of English/Hebrew
bilingualism, it is unlikely because the character set is different).
In short, the user agent is allowed to use whatever AI it is equipped with.

Markup for German AND English submissions at the same time, as per your
request:
<LABEL LANG="de" >Inhalt: <TEXTAREA NAME=INHALT ></TEXTAREA ></LABEL >
<LABEL LANG="en" >Contents: <TEXTAREA NAME=CONTENTS ></TEXTAREA ></LABEL >

HTH,
Chris





From lists.webapps at stakface.com  Thu Feb 12 07:08:59 2009
From: lists.webapps at stakface.com (Kartikaya Gupta)
Date: Thu, 12 Feb 2009 15:08:59 +0000
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <8F614BCE-F819-4466-B195-7CE7CE540030@apple.com>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
	<6AACBF67-F82E-432E-9ACC-1376F1902E9E@apple.com>
	<20090211185112.4F94D28085@mail-in11.apple.com>
	<162ED70B-388B-4FC1-9130-D796543F8D03@apple.com>
	<20090211201444.8E03428052@mail-in11.apple.com>
	<8F614BCE-F819-4466-B195-7CE7CE540030@apple.com>
Message-ID: <20090212150859.072AE14D8F3@looneymail-mx2.g.dreamhost.com>

On Wed, 11 Feb 2009 15:03:01 -0800, Darin Adler <darin at apple.com> wrote:
> 
> On Feb 11, 2009, at 12:14 PM, Kartikaya Gupta wrote:
> 
> > I updated to Safari 3.2 on Windows (which looks it also has WebKit  
> > 525.27.1) and you're right, it is now showing "number" instead of  
> > "object". I guess this was changed not too long ago. So then my  
> > question is: why was it changed?
> 
> No, this was not changed.
> 
> I don't understand why you were getting that strange result, but  
> WebKit has always shown "number" for this. I went back to old  
> versions, including digging out a copy of Safari 2 and every version I  
> tested yields a number. There was never any code that attempted to  
> return anything except a number.

Well, I don't know what to tell you. Latest version of Chrome is still giving me a Date object. I don't know what version of WebKit it's using.

> More to the point, there's also a false premise in the specification's  
> claim that this should be a Date. The Date class in JavaScript boils  
> down to a double for its internal representation; I believe that's by  
> design and not just a detail of the WebKit implementation. So the  
> claim that a number, also a double, can't handle the entire range of  
> DOMTimestamp, but the Date class can is probably incorrect. Maybe  
> someone can give a specific example with details of how this would go  
> wrong ? I don?t think there is any such example.
> 

The DOM 3 Core actually says that an "integer type" in ECMAScript is too small. The ECMA-262 spec doesn't say anything about an "integer" type; all numbers are doubles, so I have no idea what the DOM spec is referring to. However, note that section 15.9.1.1 of ECMA-262 does says that the valid range for a Date object is slightly smaller than that representable by a double (8,640,000,000,000,000 milliseconds on either side of epoch, instead of 9,007,199,254,740,991), so there is a slight difference between returning a number and returning a Date. However, in practice it's unlikely those scenarios will be hit.

Cheers,
kats


From lists.webapps at stakface.com  Thu Feb 12 07:12:49 2009
From: lists.webapps at stakface.com (Kartikaya Gupta)
Date: Thu, 12 Feb 2009 15:12:49 +0000
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <op.uo75rwo1idj3kv@zcorpandell.linkoping.osa>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
	<6AACBF67-F82E-432E-9ACC-1376F1902E9E@apple.com>
	<20090211185112.4F94D28085@mail-in11.apple.com>
	<162ED70B-388B-4FC1-9130-D796543F8D03@apple.com>
	<20090211201444.A585D14D8CC@looneymail-mx2.g.dreamhost.com>
	<op.uo75rwo1idj3kv@zcorpandell.linkoping.osa>
Message-ID: <20090212151249.DFD168ABC@looneymail-mx3.g.dreamhost.com>

On Thu, 12 Feb 2009 07:03:22 +0100, "Simon Pieters" <simonp at opera.com> wrote:
> 
> On Wed, 11 Feb 2009 21:14:44 +0100, Kartikaya Gupta <lists.webapps at stakface.com> wrote:
> 
> > I updated to Safari 3.2 on Windows (which looks it also has WebKit  
> > 525.27.1) and you're right, it is now showing "number" instead of  
> > "object". I guess this was changed not too long ago. So then my question  
> > is: why was it changed? And seeing as Opera, WebKit, and Gecko are in  
> > agreement now to return a number rather than a Date in ECMAScript, will  
> > the DOM 3 Core spec be updated? Or will this get rolled into Web DOM  
> > Core and/or HTML5?
> 
> Right now Web DOM Core says:
> 
>    A DOMTimeStamp represents a number of milliseconds. 
> 
>       typedef unsigned long long DOMTimeStamp;
> 
> 
> ...and then refers to WebIDL for what that means to ECMAScript.
> 

It seems to me the simplest approach would be to bind DOMTimeStamp to a number for ECMAScript (the typedef should then make it unnecessary to explicitly define in WebIDL), and create a new type to represent things that actually return Date objects like the HTMLInputElement.valueAsDate in HTML5. This is likely what I'll end up doing for our IDL files anyhow so that all the bindings get generated correctly.

Cheers,
kats


From simonp at opera.com  Thu Feb 12 07:22:13 2009
From: simonp at opera.com (Simon Pieters)
Date: Thu, 12 Feb 2009 16:22:13 +0100
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <200902121512.n1CFCodB011516@mx.opera.com>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
	<6AACBF67-F82E-432E-9ACC-1376F1902E9E@apple.com>
	<20090211185112.4F94D28085@mail-in11.apple.com>
	<162ED70B-388B-4FC1-9130-D796543F8D03@apple.com>
	<20090211201444.A585D14D8CC@looneymail-mx2.g.dreamhost.com>
	<op.uo75rwo1idj3kv@zcorpandell.linkoping.osa>
	<200902121512.n1CFCodB011516@mx.opera.com>
Message-ID: <op.uo8vnbmaidj3kv@zcorpandell.linkoping.osa>

On Thu, 12 Feb 2009 16:12:49 +0100, Kartikaya Gupta <lists.webapps at stakface.com> wrote:

> It seems to me the simplest approach would be to bind DOMTimeStamp to a  
> number for ECMAScript (the typedef should then make it unnecessary to  
> explicitly define in WebIDL), and create a new type to represent things  
> that actually return Date objects like the HTMLInputElement.valueAsDate  
> in HTML5. This is likely what I'll end up doing for our IDL files anyhow  
> so that all the bindings get generated correctly.

Oh yep, this seems like an issue for HTML5. Is there anything other than valueAsDate that should return a Date? Any suggestions for what I need to do in Web DOM Core?

-- 
Simon Pieters
Opera Software




From scampa.giovanni at gmail.com  Thu Feb 12 07:47:28 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Thu, 12 Feb 2009 16:47:28 +0100
Subject: [whatwg] [html5] Rendering of interactive content
In-Reply-To: <Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0902061842320.952@hixie.dreamhostps.com>
	<498DE005.2070502@googlemail.com>
	<65307430902071207l7c2db4d8yc3ff1ca8be48e22@mail.gmail.com>
	<20090208134044.GA3459@stripey.com>
	<65307430902080638n30863700jf340b3aa475ff0f4@mail.gmail.com>
	<498F1B63.5030603@googlemail.com>
	<65307430902090553t5432c8bcg846ad1ed3cc54a85@mail.gmail.com>
	<20090209142419.GA2461@stripey.com>
	<65307430902090751m49ff7669n3cf3a853d749e16f@mail.gmail.com>
	<Pine.LNX.4.62.0902110307280.28232@hixie.dreamhostps.com>
Message-ID: <65307430902120747j5620ecb9q724901b47de0bdb2@mail.gmail.com>

2009/2/11 Ian Hickson <ian at hixie.ch>

> [...]
>
> > > > 2) you depend on css3-ui, in CR stage, instead of becss, a very
>
> > > early WD
> > >
> > > BECSS is actually probably more stable than CSS3 UI at this point.
> >
> > Why do you say so? Will CSS3 UI go back to Last Call or BECSS process to
> > Last Call in the near future? I'm not sure. In the mean time, CSS3 UI is
> > final, and waiting only for implementation.
>
> CSS3 UI is very vague, and is going to need serious work before browsers
> are able to actually implement it properly. A lot of the vendor feedback
> at the time it was written was dismissed (e.g. it doesn't have a
> particularly useful or comprehensive list of appearances).
>
Well, it is the *Basic* User Interface, that is, the bare minimum. All the
rest is Advanced UI, that I hope one day we will have.


>
> > > > 3) you don't block the binding property: I don't expect that
> > > > applying an XBL binding on an element causes it to appear like a
> > > > span (because it gets almost no default CSS)
> > >
> > > This is actually intentional. Experience with elements like <fieldset>
> > > that have styles that aren't expressed in CSS is that you end up not
> > > being able to restyle them properly if you desire. With 'binding' we'd
> > > be able to knock out the whole default rendering (including weird
> > > things with the children) in one go.
> >
> > The fact is that binding it the best way to apply a set of event
> > handlers to an element. Having to tweak the computed style of a fieldset
> > in order to find what properties are actually set and reproduce them in
> > the binding, just to put a set of onchange handlers to lots of fieldset,
> > does not look optimal.
>
> I don't understand why you would need to know what properties are set, or
> what 'onchange' has to do with anything here.


<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<xbl xmlns="http://www.w3.org/ns/xbl">
<binding id="textboxes" >
<handlers><handler event="onchange">window.alert("Hey! You changed my text
box!"); </handler></handlers>
</binding>
</xbl>
<style>input[type=text] { binding: url(#textboxes); }</style>
</head>
<body><form><input type="text" value="Change me!" /></form></body>
</html>

At a first look, it just sets an onchange event handler to every
input[type=text]. Using the HTML5 approach to widgets presentation, you
would need to set the appearance to field on the bound element or it will
look much like a <span>

>
>
> [...]
> >
> > I mean that Firefox and Safari set the appearance property on the widget
> > element, and it is visible from outside, and dynamically changeable at
> > run time. The binding property instead contains an opaque and UA
> > specific value, that is not intended to be changed from JS (to switch
> > back and forth between widget types)
>
> I expect we'll define actual values for 'binding' in due course; that's
> mostly waiting on XBL2 getting implemented. I don't see why 'appearance'
> would work better with JS than 'binding'.
>
Ah ok. I thought you wanted to leave that to be implementation dependent.
This is completely different.

>
> [...]
>
> We'll probably change that to just use keywords in due course.
>
So what should be the difference between appearance: field and binding:
field ?

>
> [...]
>
>
> It's a guide to Web browser vendors who wish to render things in a
> commonly accepted way.
>

> > I think that section is for
> > - implementors of new UAs, that don't need to reverse engineer the
> > competitor products in order to find the defaults
>
> Right.
>
>
> > - authors, that in this way know what to expect from the various UA with
> > less testing, that sometimes is also impossible, eg. you cannot test the
> > rendering of a mobile phone if you don't have a mobile phone
> > Having somewhere written that hyperlinks should be blue, allows you to
> style
> > the background-color to anything but blue.
>
> The section is not really for authors (though I suppose authors might find
> it interesting, in the same way they might find the parser section
> interesting).
>
>
> [...]
>
>
> Authors should act as if the default style sheet is something sensible but
> they don't know what. (Because that is in fact what the situation is, once
> you consider user style sheets.)


That is, the rule for authors is "not just act as the UA default style sheet
was not present, but also act as if it was completely undefined or defined
to something weird", so explicitily write it every time it may be dangerous,
like for :link.

That's a completely different point of view. Thank you for clarifications,
I'll write div { display:block; } and :link { color:blue;
background-color:transparent;} in all my style sheets from now on.

Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090212/d13452fb/attachment.htm>

From bil at corry.biz  Thu Feb 12 08:05:20 2009
From: bil at corry.biz (Bil Corry)
Date: Thu, 12 Feb 2009 10:05:20 -0600
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <3729213D4D0B4544AC8D4A5935431ACC@POCZTOWIEC>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com><B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF><d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com><Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com><FE0565975932454CA24529DB469F2CAD@POCZTOWIEC><4994287D.5010204@corry.biz><4DE4A6C483D846959447EC485B0E61F8@POCZTOWIEC>	<7c2a12e20902120647o767beef5u7b7bbbbb6660b975@mail.gmail.com>
	<3729213D4D0B4544AC8D4A5935431ACC@POCZTOWIEC>
Message-ID: <499448C0.3010103@corry.biz>

Kristof Zelechovski wrote on 2/12/2009 9:05 AM: 
> Markup for German AND English submissions at the same time, as per your
> request:
> <LABEL LANG="de" >Inhalt: <TEXTAREA NAME=INHALT ></TEXTAREA ></LABEL >
> <LABEL LANG="de" >Contents: <TEXTAREA NAME=CONTENTS ></TEXTAREA ></LABEL >

In my case, we have a single field, "bug description" that may contain both English and German.  And in some cases, even a pure German bug report may reference the English form fields, such as:

	Legen Sie "City" vor "Postal Code"

In that case, there is no way for a UA or Server to auto-determine the language, even if you're aware the user speaks both German and English.

My suggestion is to leave the lang attribute out of the spec, and let the UA handle it as it wants.


- Bil



From giecrilj at stegny.2a.pl  Thu Feb 12 08:15:18 2009
From: giecrilj at stegny.2a.pl (=?utf-8?Q?K=C5=99i=C5=A1tof_=C5=BDelechovski?=)
Date: Thu, 12 Feb 2009 17:15:18 +0100
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <499448C0.3010103@corry.biz>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com><B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF><d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com><Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com><FE0565975932454CA24529DB469F2CAD@POCZTOWIEC><4994287D.5010204@corry.biz><4DE4A6C483D846959447EC485B0E61F8@POCZTOWIEC>	<7c2a12e20902120647o767beef5u7b7bbbbb6660b975@mail.gmail.com><3729213D4D0B4544AC8D4A5935431ACC@POCZTOWIEC>
	<499448C0.3010103@corry.biz>
Message-ID: <5A3B7C569A6B47F7991C966565BA366E@POCZTOWIEC>

Having interjected words marked as spelling errors is not a failure.  The same phenomenon occurs with proper names and you cannot help that.
The UI you described is inconsistent and it should be fixed.  The control for German should be labeled "Fehlerbe?chreibung" or whatever.
Best regards,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Bil Corry
Sent: Thursday, February 12, 2009 5:05 PM
To: whatwg at whatwg.org
Subject: Re: [whatwg] Spellchecking mark III

Kristof Zelechovski wrote on 2/12/2009 9:05 AM: 
> Markup for German AND English submissions at the same time, as per your
> request:
> <LABEL LANG="de" >Inhalt: <TEXTAREA NAME=INHALT ></TEXTAREA ></LABEL >
> <LABEL LANG="de" >Contents: <TEXTAREA NAME=CONTENTS ></TEXTAREA ></LABEL >

In my case, we have a single field, "bug description" that may contain both English and German.  And in some cases, even a pure German bug report may reference the English form fields, such as:

	Legen Sie "City" vor "Postal Code"

In that case, there is no way for a UA or Server to auto-determine the language, even if you're aware the user speaks both German and English.

My suggestion is to leave the lang attribute out of the spec, and let the UA handle it as it wants.


- Bil




From lists at rikkertkoppes.com  Thu Feb 12 08:30:01 2009
From: lists at rikkertkoppes.com (Rikkert Koppes)
Date: Thu, 12 Feb 2009 17:30:01 +0100
Subject: [whatwg] False orthogonal nature :read-only and :disabled in WF2
In-Reply-To: <Pine.LNX.4.62.0902110806580.28232@hixie.dreamhostps.com>
References: <43FAE36B.6000603@earthlink.net>	<Pine.LNX.4.62.0608150029010.5340@dhalsim.dreamhost.com>	<44E1A463.4010404@earthlink.net>
	<Pine.LNX.4.62.0902110806580.28232@hixie.dreamhostps.com>
Message-ID: <49944E89.9080604@rikkertkoppes.com>

Either I am rather confused or there are some misunderstandings still. 
Some observations:

Ian Hickson wrote:
>>> Having them be orthogonal is far more useful to authors. For example, 
>>> imagine the following stylesheet:
>>>       
And
> I've made HTML5 say that :read-write doesn't apply to disabled controls.
>
>   
(1) If :read-write does not apply to disabled controls, :read-only does 
(since it applies to all other html elements - meaning they are mutually 
exclusive). Hence :disabled implies :read-only (not vice versa for the 
record) and hence :disabled and :read-only are not orthogonal.

The spec now says :read-write does not apply to input elements that do 
NOT have the readonly attribute specified AND that are NOT disabled, or 
in other words (by mutual exclusivity), :read-only applies to input 
elements that have the readonly attribute specified OR are disabled.

Grtz,
Rikkert Koppes


From bzbarsky at MIT.EDU  Thu Feb 12 08:41:20 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 12 Feb 2009 11:41:20 -0500
Subject: [whatwg] defer on style, depends
In-Reply-To: <c9e12660902112343q33aeac40i5c791ae5d81760a6@mail.gmail.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>	
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>	
	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>	
	<Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com>	
	<c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>	
	<49906AFA.804@mit.edu>	
	<c9e12660902091056t10eba8d1i91bcb8f9bda3a528@mail.gmail.com>	
	<49908A11.6070905@mit.edu>	
	<c9e12660902091815q3a659cf6q592ab7844f7b179f@mail.gmail.com>	
	<4990F667.5060701@mit.edu>
	<c9e12660902112343q33aeac40i5c791ae5d81760a6@mail.gmail.com>
Message-ID: <49945130.7070703@mit.edu>

Garrett Smith wrote:
>> I would be fine with a way to flag scripts with that information, though
>> there is a catch-22: if you flag such a script and it DOES depend on style
>> information, then existing UAs will get it "right" and any UA implementing
>> the new spec will get it "wrong".
>>
> 
> If the page does what it is designed to do, and that the design is
> flawed, the page would be broken by design. Designing things to be
> broken would be "wrong".

My point is that if no UAs implement the new stuff it's easy to make 
such a mistake, and then UAs that _do_ implement it will show your page 
not as you intended.

In other words, widespread adoption of this in authoring before 
implementation would actually raise a bar to implementation, since it 
raises the chances that implementing the feature will break sites.

Hence the catch-22 mention above.
  >>>> Not sure what this example is, or why this is insufficienty 
served by,
>>>> say,
>>>> putting the <link> at the end of the HTML (assuming HTML allowed that, of
>>>> course).
>>> Are you proposing HTML allow that?
>> That's one possible solution to the issue of starting stylesheet loads as
>> late as possible, yes.  It's not a great one a priori, but has the benefit
>> of good compat with existing UAs (which you said was a priority for you).
> 
> Not that I think you are wrong, but that statement ought to be backed
> up by some tests.

You mean tests showing that current UAs allow <link rel="stylesheet"> at 
the end of <body>?

> No, just observing that the problem could have been avoided with a
> "depends=" attribute, if only such attribute had existed c2000, and
> having scripts wait only when depends is set. I like this design.

That's nice, but the question is where we can go now given the current 
situation, not the one that existed 10 years ago.

>>> An "independent" attribute on a link says that a browser does not need
>>> to wait for that resource to finish loading before it loads other
>>> resources (like loading a script). When the parser parses that
>>> "independent" attribute, it sets a flag for the browser go ahead and
>>> download and run any subsequent script.
>> That doesn't work for today's browsers, though, just like flagging the
>> script doesn't.  Or am I missing something?
> 
> You got it. It doesn't work for today's browsers. However, it isn't
> guaranteed *not* to work by any standard. In fact, browsers behave
> differently on the matter. Could this new feature result in breaking
> code in older browsers?

No, but my point is that if you're concerned about solutions due to 
their impact on old browsers, then this solution has the same impact as 
all the things Ian has proposed...

> You say that stylesheets do not block script loading. That may be true
> of "Shiretoko" 1.9.1, however, that is not what I see for Firefox 3.0.
> The example I posted shows that stylesheets hold up body content from
> rendering. If that content contains a script tag, the script will
> *not* load *or* run.

I can tell you for a fact, having implemented this part of Gecko myself, 
that a stylesheet will prevent body content from _rendering_, but NOT 
from being parsed.  It will furthermore not prevent scripts from 
loading, but _will_ prevent them from running.

I can point you to the relevant code if desired.

> The following example shows this to be true:
> http://dhtmlkitchen.com/jstest/block/link-external.html

This example demonstrates that pending script execution blocks parsing 
and hence script loading in Gecko 1.9.0.  In fact, it says so right in 
the example.  That's not the same thing as stylesheets blocking script 
loading.

And yes, in Gecko 1.9.1 the speculative parser will likely kick off all 
the script loads while still waiting for the stylesheet in this case.

> The only explanation I have for this behavior is that the browser is
> waiting for the stylesheet to complete before it requests the script
> in the body.

No, it's waiting for the <head> scripts to execute before parsing the 
body and requesting the script.  Those scripts happen to be waiting for 
the stylesheet, but if you didn't have them there the script in the 
<body> would be loaded in parallel with the stylesheet.

Heck, you don't even need the external script in <head>.  The inline one 
would give you the same behavior.

> That is why it would be better for performance to have
> that script prefetched

Something that UAs are working on anyway, with speculative parsing used 
to prefetch content.  That's happening in at least Webkit and Gecko.

>> What I said was true for all scripts.  We do not differentiate between
>> content in <head> and content in <body> in this regard.
> 
> In Shiretoko 3.1, true, but in Firefox 3.1, the bottom script is not
> loaded.

That has nothing to do with <head> vs <body>, as you could trivially 
test by moving those scripts around in your document.  All that matters 
is the order of the script tags.

>>> However, external resources such as SCRIPT or IMG that appear in the
>>> BODY will not get requested by the browser until the page content
>>> renders.
>> You mean until all the HTML before the tag has been parsed?  Or something
>> else?  There's no dependency between script loading+execution and page
>> rendering, in Gecko.  Heck, you can run scripts in a display:none iframe,
>> with no rendering in sight.
> 
> By "all the HTML before the tag has been parsed," I think you mean,
> all the HTML before the tag for that IMG or SCRIPT resource.

Correct.

> Next you're saying that visual display is not correlated to
> script loading or script execution.

Correct.

> I'm not sure how this is related.

You keep talking about "until the page content renders", which is visual 
display.

> In Shiretoko, a script, even a deferred script, will not run until the
> stylesheet is loaded.

Correct.

> Can we make an improvement on that, or to make that improvement
> configurable to the page author?

I think we can, sure.  In fact I'm proposing flagging scripts that don't 
depend on stylesheets, no?

>> Ah, that is one thing that Gecko does do: we don't start _layout_ (as
>> opposed to parsing) until all the stylesheets in <head> have loaded.
> 
> For Firefox 3.0, IMG and SCRIPT that are part of the body are fetched
> around this time. They are not fetched prior. Why not?

Because you have <script>s after your stylesheets, not just stylesheets. 
  Really, controlled experiments are hard.  You have to hold all but one 
variable constant.

> In that case, the link would not block layout.

Yes, which is why you get a performance hit when it loads.  But I 
thought we were talking about stylesheets that don't "really" affect 
layout (late-loading stylesheets, which you wanted).

> In "Shiretoko" 1.9.1b3pre, a deferred script waits for all stylesheets
> to load before running. However, this is not guaranteed behavior in
> any standard.

True.  At least not yet.  I suspect it's pretty much required for web 
compat, though, which is why it's implemented that way.  Or at the very 
least the scripts need to wait for the stylesheets that came before them.

>>> Question: When the stylesheet is eventually applied, could the reflow
>>> be optimized for performance?
>> Not easily, no.  Or rather, the reflow already is; the style data
>> recomputation is the hard part.
> 
> What would make it easier? I'd really like to know how to design my
> pages so that they are faster and more responsive.

Well, one option is to stop worrying about micromanaging the load order 
and assume that speculative parsing will solve your problems.... will it?

> A deferred stylesheet being requested by the browser would not be a
> problem. Mozilla already makes predictive fetches for links. However,
> if a deferred stylesheet is fetched during loading, should that
> stylesheet (and rules.length, etc) be accessible via script in that
> time? Should the deferred link fire a load event after the request
> completes?

In my opinion, prefetching should have no effect on what the DOM sees. 
It should just make it look like the network load took a lot less time 
than it would otherwise.

In other words, you load the stylesheet, parse it, whatever, but don't 
hook it up to the document until you "really" parse the <link> tag.

-Boris


From bil at corry.biz  Thu Feb 12 09:01:29 2009
From: bil at corry.biz (Bil Corry)
Date: Thu, 12 Feb 2009 11:01:29 -0600
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <5A3B7C569A6B47F7991C966565BA366E@POCZTOWIEC>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com><B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF><d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com><Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com><FE0565975932454CA24529DB469F2CAD@POCZTOWIEC><4994287D.5010204@corry.biz><4DE4A6C483D846959447EC485B0E61F8@POCZTOWIEC>	<7c2a12e20902120647o767beef5u7b7bbbbb6660b975@mail.gmail.com><3729213D4D0B4544AC8D4A5935431ACC@POCZTOWIEC>	<499448C0.3010103@corry.biz>
	<5A3B7C569A6B47F7991C966565BA366E@POCZTOWIEC>
Message-ID: <499455E9.5060005@corry.biz>

K?i?tof ?elechovski wrote on 2/12/2009 10:15 AM: 
> The UI you described is inconsistent and it should be fixed.

Inconsistent with which UI standard?


- Bil



From giecrilj at stegny.2a.pl  Thu Feb 12 09:06:00 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Thu, 12 Feb 2009 18:06:00 +0100
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <499455E9.5060005@corry.biz>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com><B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF><d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com><Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com><FE0565975932454CA24529DB469F2CAD@POCZTOWIEC><4994287D.5010204@corry.biz><4DE4A6C483D846959447EC485B0E61F8@POCZTOWIEC>	<7c2a12e20902120647o767beef5u7b7bbbbb6660b975@mail.gmail.com><3729213D4D0B4544AC8D4A5935431ACC@POCZTOWIEC>	<499448C0.3010103@corry.biz><5A3B7C569A6B47F7991C966565BA366E@POCZTOWIEC>
	<499455E9.5060005@corry.biz>
Message-ID: <7C40F874CD9A40EDBF203BA54F56D748@POCZTOWIEC>

I do not know much about UI standards but the rule that the answer should be
formulated in the language of the question is rather straightforward.  It is
just common sense.  Exceptions are questions like "How is that in German?".
Chris






From darin at apple.com  Thu Feb 12 09:51:02 2009
From: darin at apple.com (Darin Adler)
Date: Thu, 12 Feb 2009 09:51:02 -0800
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <20090212150900.18B70280D8@mail-in11.apple.com>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
	<6AACBF67-F82E-432E-9ACC-1376F1902E9E@apple.com>
	<20090211185112.4F94D28085@mail-in11.apple.com>
	<162ED70B-388B-4FC1-9130-D796543F8D03@apple.com>
	<20090211201444.8E03428052@mail-in11.apple.com>
	<8F614BCE-F819-4466-B195-7CE7CE540030@apple.com>
	<20090212150900.18B70280D8@mail-in11.apple.com>
Message-ID: <0F82CF51-E215-4637-A0C1-DDDFC0813136@apple.com>

On Feb 12, 2009, at 7:08 AM, Kartikaya Gupta wrote:

> Latest version of Chrome is still giving me a Date object. I don't  
> know what version of WebKit it's using.

Chrome uses an entirely different JavaScript binding, not the standard  
WebKit one, so I'm not surprised that it?s exhibiting different  
behavior.

     -- Darin



From bil at corry.biz  Thu Feb 12 10:04:08 2009
From: bil at corry.biz (Bil Corry)
Date: Thu, 12 Feb 2009 12:04:08 -0600
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <7C40F874CD9A40EDBF203BA54F56D748@POCZTOWIEC>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com><B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF><d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com><Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com><FE0565975932454CA24529DB469F2CAD@POCZTOWIEC><4994287D.5010204@corry.biz><4DE4A6C483D846959447EC485B0E61F8@POCZTOWIEC>	<7c2a12e20902120647o767beef5u7b7bbbbb6660b975@mail.gmail.com><3729213D4D0B4544AC8D4A5935431ACC@POCZTOWIEC>	<499448C0.3010103@corry.biz><5A3B7C569A6B47F7991C966565BA366E@POCZTOWIEC>	<499455E9.5060005@corry.biz>
	<7C40F874CD9A40EDBF203BA54F56D748@POCZTOWIEC>
Message-ID: <49946498.8010904@corry.biz>

Kristof Zelechovski wrote on 2/12/2009 11:06 AM: 
> I do not know much about UI standards but the rule that the answer should be
> formulated in the language of the question is rather straightforward.  It is
> just common sense.  Exceptions are questions like "How is that in German?".

No one can control the language a user will choose to use in a textarea, regardless of the label used to describe it.

Providing a localized textarea for every language might increase the odds of the user using the language the server prefers, but there is no guarantee.  And I'm unclear what problem that would ultimately solve.


- Bil



From dgerard at gmail.com  Thu Feb 12 10:09:52 2009
From: dgerard at gmail.com (David Gerard)
Date: Thu, 12 Feb 2009 18:09:52 +0000
Subject: [whatwg] Fwd: [html5] Semantic elements and spec complexity
In-Reply-To: <Pine.LNX.4.62.0902112140510.952@hixie.dreamhostps.com>
References: <412901B0.3070500@annevankesteren.nl>
	<Pine.LNX.4.61.0408281349300.8458@dhalsim.dreamhost.com>
	<4130B594.2000006@annevankesteren.nl>
	<Pine.LNX.4.61.0411091436280.4110@dhalsim.dreamhost.com>
	<689CD652-3320-11D9-8ACF-000A95AD3972@myrealbox.com>
	<41924EDD.7000602@cam.ac.uk>
	<Pine.LNX.4.62.0902100625270.28232@hixie.dreamhostps.com>
	<fbad4e140902111334m315fdb1cr48e2d71c03e6703c@mail.gmail.com>
	<fbad4e140902111334v118cac83ya495fdfa7a892785@mail.gmail.com>
	<Pine.LNX.4.62.0902112140510.952@hixie.dreamhostps.com>
Message-ID: <fbad4e140902121009j4fea2971re8b01c670a61e0cf@mail.gmail.com>

2009/2/11 Ian Hickson <ian at hixie.ch>:
> On Wed, 11 Feb 2009, David Gerard wrote:

>> Think of tag-soupness as a feature, not a bug. Shudder in horror at what
>> this implies.

> I don't think that's a particularly controversial position here. People in
> other mailing lists involved in the development of HTML5 might disagree. :-)


It's definitely a feature, not a bug, in Wikitext - Wikipedia has many
contributors who write great articles but basically can't work a
computer otherwise. If it wasn't, Wikipedia would be written in
immaculately nested XML ... and XML was expressly *not* designed for
humans to write, but for machines to talk to each other.

Whether it's a feature for HTML, well, I suspect the people who write
parsers have a few choice words on the matter ;-)


- d.


From giecrilj at stegny.2a.pl  Thu Feb 12 10:13:57 2009
From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=)
Date: Thu, 12 Feb 2009 19:13:57 +0100
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <49946498.8010904@corry.biz>
References: <d62cf1d10901280947l710b59fev58c24ea0c70206d4@mail.gmail.com><B0E56D7DDB53498A9AAE62C86056FB38@IBM42F76C011DF><d62cf1d10901281032s42055139i7805dee20c9727c8@mail.gmail.com><Pine.LNX.4.62.0902120703540.28232@hixie.dreamhostps.com><FE0565975932454CA24529DB469F2CAD@POCZTOWIEC><4994287D.5010204@corry.biz><4DE4A6C483D846959447EC485B0E61F8@POCZTOWIEC>	<7c2a12e20902120647o767beef5u7b7bbbbb6660b975@mail.gmail.com><3729213D4D0B4544AC8D4A5935431ACC@POCZTOWIEC>	<499448C0.3010103@corry.biz><5A3B7C569A6B47F7991C966565BA366E@POCZTOWIEC>	<499455E9.5060005@corry.biz><7C40F874CD9A40EDBF203BA54F56D748@POCZTOWIEC>
	<49946498.8010904@corry.biz>
Message-ID: <FF4C2B05B75C4078BBCEF1BDD0536637@POCZTOWIEC>

The majority of users will answer the question in the language of the
question, this is the normal reaction.  Of course there is no guarantee but
the odds of getting the expected result are high.  Assuming that the user's
input will actually be read by somebody, providing proper markup will help
the readers to get something they are able to read.
Chris





From derhoermi at gmx.net  Thu Feb 12 11:29:10 2009
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Thu, 12 Feb 2009 20:29:10 +0100
Subject: [whatwg] DOMTimeStamp binding
In-Reply-To: <E1LXJ35-0002nf-LM@maggie.w3.org>
References: <E1LXJ35-0002nf-LM@maggie.w3.org>
Message-ID: <krt8p4pdeh900hfcpco2b7bca5cqh4l7ia@hive.bjoern.hoehrmann.de>

* Kartikaya Gupta wrote:
>DOM 3 Core says this about DOMTimeStamp:
>
>> For Java, DOMTimeStamp is bound to the long type. For ECMAScript, DOMTimeStamp
>> is bound to the Date type because the range of the integer type is too small.

The former WebAPI working group discussed this issue and found that the
reasoning behind this was bogus and, taking into account deployed imple-
mentations resolved, to change the binding to the Number type. DOM Level
3 Events does as much, along with pointing out the Group's intent to up-
date DOM Level 3 Core accordingly (see the "Changes" appendix).
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 


From fantasai.lists at inkedblade.net  Thu Feb 12 12:13:45 2009
From: fantasai.lists at inkedblade.net (fantasai)
Date: Thu, 12 Feb 2009 12:13:45 -0800
Subject: [whatwg] Selectors Tests and :enabled
In-Reply-To: <Pine.LNX.4.62.0902112340160.952@hixie.dreamhostps.com>
References: <49071641.4000609@lachy.id.au> <4908C0BD.8090108@inkedblade.net>
	<4908D475.5060701@lachy.id.au>
	<Pine.LNX.4.62.0902110824030.28232@hixie.dreamhostps.com>
	<4993547C.5010701@inkedblade.net>
	<Pine.LNX.4.62.0902112340160.952@hixie.dreamhostps.com>
Message-ID: <499482F9.1080500@inkedblade.net>

Ian Hickson wrote:
> On Wed, 11 Feb 2009, fantasai wrote:
>> Given the state of current implementations and the fact that hidden input
>> elements do have distinct enabled and disabled states, I don't understand
>> the reasoning behind this change.
>>   http://twitter.com/WHATWG/status/1198455588
> 
> The idea was to match Selectors.
> ...
> I see this has now changed. I will update HTML5 in due course to match 
> the new text in Selectors.
> 
> (I'll also update my spec index to point to the dev.w3.org link instead of 
> the /TR/ page so that I don't make this mistake again.)

Ok. I'll ping you once we publish a new draft (which, hopefully, should
be within a week or two).

~fantasai


From lists.whatwg at stakface.com  Thu Feb 12 14:25:04 2009
From: lists.whatwg at stakface.com (Kartikaya Gupta)
Date: Thu, 12 Feb 2009 22:25:04 +0000
Subject: [whatwg] Script/parser interaction bug?
In-Reply-To: <Pine.LNX.4.62.0902120645590.28232@hixie.dreamhostps.com>
References: <20090120004348.78E3B828E@looneymail-mx3.g.dreamhost.com>
	<Pine.LNX.4.62.0902120645590.28232@hixie.dreamhostps.com>
Message-ID: <20090212222514.C75B314D91B@looneymail-mx2.g.dreamhost.com>

On Thu, 12 Feb 2009 06:55:18 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> 
> Could you reannotate the above but with the script nesting level 
> explicitly given at each step?
> 


Below is an updated annotation including all the script nesting level and parser pause flag changes.
(Original annotation at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-January/018289.html)

- initially, script nesting level is zero, parser pause flag is false
- tokenize/treebuild ext7.html until the first closing script tag is found (for the 7a.js script)
- increment the script nesting level to 1
- the 7a.js script tag has a src attribute, so it gets set as the pending external script
- decrement the script nesting level to zero
- since the script nesting level is zero, set the parser pause flag to false (it was already false)
- execute the pending external script (7a.js) (this clears the pending external script pointer)
--- insert "<script src=ext7b.js></script>" into the input stream
--- tokenize/treebuild the 7b.js script tag until the </script> for 7b.js is found
--- increment the script nesting level to 1
--- the 7b.js script tag has a src attribute, so it gets set as the pending external script
--- decrement the script nesting level to zero
--- since the script nesting level is zero, set the parser pause flag to false (it was already false)
--- there is a pending external script (7b.js) but the tree construction stage is re-entrant, so set parser pause flag to true and return
--- insert remaining document.write content from 7a.js into the input stream. since there is a pending external script, none of it gets tokenized/treebuilt
- 7a.js finishes executing. at this point the script nesting level is zero and the parser pause flag is true
- check again for a pending external script. there is one, 7b.js
- execute the pending external script (7b.js) (this clears the pending external script pointer)
--- throws
- 7b.js finishes executing. at this point the script nesting level is zero and the parser pause flag is true
- continue processing the input stream (this now has the contents of the document.write calls from 7a.js, line 2 onwards)
- tokenize/treebuild the input stream until the </script> at the bottom of 7a.js is encountered
- increment the script nesting level to 1
- the script tag does not have a src attribute, so it gets executed
--- insert the div into the input stream
--- since the parser pause flag is true the div does NOT get tokenized/treebuilt
--- run the line that sets .firstChild.data to PASS. since the div isn't in the DOM yet, this throws
- the script written from 7a.js finishes executing. at this point the script nesting level is 1 and the parser pause flag is true
- decrement the script nesting level to zero
- since the script nesting level is zero, set the parser pause flag to false
- continue processing the input stream (this now contains just the div tag with FAIL inside)
- tokenize/treebuild the input stream, which adds the FAIL div to the DOM
- done

Cheers,
kats


From robert at ocallahan.org  Thu Feb 12 14:55:52 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 13 Feb 2009 11:55:52 +1300
Subject: [whatwg] Author control over media preloading/buffering
In-Reply-To: <26b395e60902120113h6b87b58dva9707d843009378e@mail.gmail.com>
References: <11e306600902102020w785ea140v48e21304b96da8ef@mail.gmail.com>
	<26b395e60902120113h6b87b58dva9707d843009378e@mail.gmail.com>
Message-ID: <11e306600902121455h5d38ea3n7bdebdfb2a357504@mail.gmail.com>

On Thu, Feb 12, 2009 at 10:13 PM, timeless <timeless at gmail.com> wrote:

> 2009/2/11 Robert O'Callahan <robert at ocallahan.org>:
> > So, how about adding an "autobuffer" attribute, which instructs the
> browser that the user
> > will probably play the video and as much data as possible should be
> pre-downloaded?
>
> > By default (when the attribute is not present) the browser would be
> expected to pause
> > the download after reaching HAVE_CURRENT_DATA if the media element is
> paused and not 'autoplay'.
>
> if i'm a mobile browser vendor (and I am), and if I expect to use
> Bluetooth to talk to a cell phone which has high bandwidth costs (and
> if you're using an n800/n810 tethered to a phone in Canada, this is
> true), then, i'm not sure I really want web pages to specify things
> quite like this.


Then you can have the browser ignore "autobuffer". Problem solved.


> bufferpriority="1", bufferpriority="2", which establish a sort and
> inform the browser which videos are most important, and the browser
> can then choose to collect as many of them as it feels comfortable
> collecting, possibly to the point that having played the highest
> priority, it proceeds to buffer the next highest priority video. If
> there are two things w/ bufferpriority="2", then the browser is free
> to treat them equally, but having already played one, it would then
> favor the other.
>

I don't really see a usecase for multiple priority levels. Do you have one?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090213/ba77bbdd/attachment.htm>

From ian at hixie.ch  Thu Feb 12 17:54:50 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Feb 2009 01:54:50 +0000 (UTC)
Subject: [whatwg] HTML5 fo ecommerce
In-Reply-To: <2abc5f2d0901230010padb8502k10e4e8483836fdd6@mail.gmail.com>
References: <2abc5f2d0901230010padb8502k10e4e8483836fdd6@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902130149250.28232@hixie.dreamhostps.com>

On Fri, 23 Jan 2009, Mynthon wrote:
> 
> I have some questions about html. I really like new <section /> tag and 
> its possibility to have its own <hx /> structure. Dont like mixing <hx 
> /> levels but thats BTW.
> 
> I have strange feeling that in next 5 years not only blogs will be 
> available on the web but also some e-commerce pages (online shop, 
> auctions). Also some new applications. Now i cant figure out how to use 
> html5 for those sites.
> 
> On my companys page there are no articles and sections. There are 
> products and product lists. Isnt it wrong to use
> 
> <article>
>   <section>
>     <h1>product1</h1>
>     some data
>   </section>
>   <section>
>     <h1>product2</h1>
>     some data
>   </section>
>   <section>
>     <h1>product3</h1>
>     some data
>   </section>
> </article>
> 
> while it wil be misleading screen readers? For users without 
> disabilities there is no problem but for eg. blind peple? Calling 
> product list an article is... hmmm... wrong.

Yup. Don't do it. :-)


> The same goes for pages with advertisements and announcements, e-mail 
> web frontends, forums, and every other page that is not blog or 
> newspage. If there are new tags for blogs (<article />, <section />, 
> <audio />, <video />) are there plans for tags usable for other pages 
> (<product />, <productlist />, <price />, <subject />, <thread />, 
> <announcement />, <review /> etc.)

There are no plans for this in HTML5 (though maybe in HTML6).

If you have a (product) list, then we have <ul> and <ol>. Threads (like in 
forums) can be represented with nested <article> elements; that's part of 
what that element is for -- a post is considered an article, in fact a 
forum post is the very first example in the spec.


> Something like:
> <product>
>   <h1>New book</h1>
>   <p>by Chris Grabowski</p>
>   <p>old price: <span>5usd</span></p>
>   <p><strong>Now only:</strong> <price>3.99usd</price></p>
>   <p>This is description of product ...</p>
> </product>
> 
> Will be very cool for me and many other.

I think using <section> for this is fine, along with some classes:

  <section class="product">
   <header>
    <h1>New book</h1>
    <p>by Chris Grabowsky</p>
   </header>
   <p>Old price: <span>5 USD</span></p>
   <p><strong>Now only:</strong> <span class="price">3.99USD</span></p>
   <p>This is description of product ...</p>
  </section>

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb 12 19:06:58 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Feb 2009 03:06:58 +0000 (UTC)
Subject: [whatwg] 5.7.6 The application cache selection algorithm
In-Reply-To: <fa2eab050901291207g40b8aa50n6ed12b92237e2baa@mail.gmail.com>
References: <fa2eab050901281739o6107e51bh7faa4e35994a9d86@mail.gmail.com> 
	<Pine.LNX.4.62.0901290147430.952@hixie.dreamhostps.com> 
	<fa2eab050901281826j3fced63es4ce5be5a880ac652@mail.gmail.com> 
	<Pine.LNX.4.62.0901290231030.952@hixie.dreamhostps.com>
	<fa2eab050901291207g40b8aa50n6ed12b92237e2baa@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902130305420.28232@hixie.dreamhostps.com>

On Thu, 29 Jan 2009, Michael Nordman wrote:
> >> >
> >> > Note that the "document-is-markup" flag will likely go away, and be 
> >> > replaced by just checking to see if there is a manifest (as it was 
> >> > before).
> >
> > The reason this particular thing might change is that I checked it in 
> > yesterday and this morning one of the Apple guys complained to me on 
> > IRC about it, pointing out it was a change from the earlier text and 
> > that he thought the earlier text made more sense. :-)
> 
> The behavior of HTML resources listed in the manifest but not having a 
> manifest= attribute would be very different if this change is adopted. 
> Unless somebody has learned something concrete from experience with this 
> system to indicate that this change is called for... probably should be 
> backed out.
> 
> I can imagine cases where this change would be difficult to deal with. 
> For example a static HTML page could not be incorporated into more than 
> one appcache. If you have a system that provides an appcache per user 
> (say by virtue of dynamically generated top level pages containing 
> manifest attributes), your only option would be to dynamically generate 
> all HTML resources within that cache to contain the appropiate manifest 
> attribute.

I've changed it so that XML and HTML files that don't have an explicit 
manifest will get fetched from an appcache if there is one from the same 
origin. (If someone _adds_ a manifest, then the cache will get updated 
with that new URL, and if the user goes back to that page, then it'll fail 
to load from the apocache since it is now foreign.)

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb 12 19:10:31 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Feb 2009 03:10:31 +0000 (UTC)
Subject: [whatwg] swapCache algorithm changes
In-Reply-To: <B76A50E5-3BC5-4B3C-BEDB-C56F277BDD91@webkit.org>
References: <B76A50E5-3BC5-4B3C-BEDB-C56F277BDD91@webkit.org>
Message-ID: <Pine.LNX.4.62.0902130309540.28232@hixie.dreamhostps.com>

On Fri, 30 Jan 2009, Alexey Proskuryakov wrote:
> 
> I've noticed that swapCache() now raises an exception if the cache's 
> application cache group is marked as obsolete. Previously, this resulted 
> in the document being unassociated from the cache.
> 
> Why such a change? It seems arbitrary - the previous behavior made good 
> sense.

I've switched it back to the old unassociating behavior.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb 12 19:15:42 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Feb 2009 03:15:42 +0000 (UTC)
Subject: [whatwg] Methods defined for one document called after that
 document is no longer the one being displayed
In-Reply-To: <49851262.8060300@mit.edu>
References: <Pine.LNX.4.62.0808050759070.5140@hixie.dreamhostps.com>
	<278fd46c0808050133t40c3f562u25d0586fe30067f3@mail.gmail.com>
	<Pine.LNX.4.62.0808050835100.5136@hixie.dreamhostps.com>
	<Pine.LNX.4.62.0812200947130.30225@hixie.dreamhostps.com>
	<D0508AD1-F4DC-4BCE-BFD9-D07D02C7F0A0@apple.com>
	<Pine.LNX.4.62.0901311022330.14270@hixie.dreamhostps.com>
	<49851262.8060300@mit.edu>
Message-ID: <Pine.LNX.4.62.0902130315210.28232@hixie.dreamhostps.com>

On Sat, 31 Jan 2009, Boris Zbarsky wrote:
>
> Ian Hickson wrote:
> > I haven't mentioned the 'this' behavior, so right now |this !=== 
> > window|, which breaks the invariant that there is no way to actually 
> > get hold of a reference to the Window object itself (as opposed to the 
> > outer WindowProxy object that forwards to the inner Window object). 
> > This requirement would be a violation of ECMAScript 3.1, so if we 
> > could get that changed in ES3.1, that would be great. Failing that, it 
> > should probably be in the WebIDL JavaScript binding section.
> 
> As I recall, in Gecko the keyword |this| evaluates to the outer window.  
> I'm not sure what happens to the implicit |this| that's computed when 
> defining a global function, say.
> 
> The reason for this setup was precisely to prevent script from getting a 
> handle to the inner Window.  Since we do security checks for cross-site 
> scripting in the outer Window, any ability to pass inner Windows 
> cross-site would be an automatic security hole.
> 
> The setup as it exists right now allows scripts that run within a single 
> window and never explicitly touch Window objects to not have to perform 
> security checks on every property access.
> 
> You might want to double-check with Blake Kaplan, Brendan Eich, or 
> Johnny Stenback on the above, as well as on how this fits in with 
> ECMAScript 3.1.  I seem to recall something about that going by in the 
> bugs when this was being worked on, but Brendan is more likely to recall 
> the details than I am to be able to find them...

I've pinged Brendan about this, but on the short term, I've put the 
requirement in HTML5, so that we don't lose it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb 12 19:23:35 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Feb 2009 03:23:35 +0000 (UTC)
Subject: [whatwg] Semi-transparent content models
In-Reply-To: <498659E1.1060906@lachy.id.au>
References: <498659E1.1060906@lachy.id.au>
Message-ID: <Pine.LNX.4.62.0902130323280.28232@hixie.dreamhostps.com>

On Mon, 2 Feb 2009, Lachlan Hunt wrote:
>
>   The spec defines the semi-transparent content model, but this is no 
> longer used for any elements.  Please remove this from the spec.
> 
> http://www.whatwg.org/specs/web-apps/current-work/#transparent-content-models

Done.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb 12 19:26:27 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Feb 2009 03:26:27 +0000 (UTC)
Subject: [whatwg] 5.12.3.7 Link type "help"
In-Reply-To: <65307430902031242s98dfb69t53e5f448d2e7020e@mail.gmail.com>
References: <49878C57.5080605@amooma.de>
	<65307430902031242s98dfb69t53e5f448d2e7020e@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0902130325320.28232@hixie.dreamhostps.com>

On Tue, 3 Feb 2009, Philipp Kempgen wrote:
>
> ---cut---
> 5.12.3.7 Link type "help"
> The help keyword may be used with link, a, and area  elements.
> For link elements, it creates a hyperlink.
> ---cut---
> 
> Shouldn't that read "For *a* elements, it creates a hyperlink."?

On Tue, 3 Feb 2009, Giovanni Campagna wrote:
>
> <a> elements are always hyperlinks, <link> can be hyperlinks or 
> resources. So it only makes sense for the <link> element to be 
> explicitly marked like this.

What Giovanni said. :-) Hopefully this is more obvious if you look at the 
other link types as well.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb 12 21:00:04 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Feb 2009 05:00:04 +0000 (UTC)
Subject: [whatwg] List Headers
In-Reply-To: <498AAC7E.4080009@googlemail.com>
References: <49896A54.2040607@sanchothefat.com>
	<6BC3A580-957F-481D-B9F8-7B7A13162601@pha.hk>
	<498972DB.1060107@lachy.id.au>
	<c9e12660902041239n395f3c18o1e76441049e7b03c@mail.gmail.com>
	<498A02A7.9050904@googlemail.com> <498AA0BB.9030501@gmx.ch>
	<498AAC7E.4080009@googlemail.com>
Message-ID: <Pine.LNX.4.62.0902130334040.28232@hixie.dreamhostps.com>

On Wed, 4 Feb 2009, Lachlan Hunt wrote:
> > 
> > You can do this in HTML5, using <figure> and <legend>:
> > 
> >    <figure>
> >     <legend>A header for the list</legend>
> >     <ul>
> >      <li>List item</li>
> >      <li>List item</li>
> >      <li>List item</li>
> >     </ul>
> >    </figure>
> 
> Since figure is a sectioning root, a heading element could also be used 
> here and it wouldn't affect the outline.  Please add an example of this 
> use case to the spec.

I considered this, but frankly <ol>, <ul>, and <figure> already have a 
whole bunch of examples, and it turns out <li> already has an example of a 
list in a <figure> element.


On Thu, 5 Feb 2009, Markus Ernst wrote:
> 
> A different use case in the same problem field: Often you have lists 
> that are actually part of a paragraph, but cannot be correctly 
> associated with the paragraph:
> 
> <p>Text before ...</p>
> <p>There are lots of fruits available, e.g.:</p>
> <ul>
>   <li>Apples</li>
>   <li>Pears</li>
> </ul>
> <p>More Text...</p>
> 
> More appropriate markup for this could be achieved with the LH 
> suggestion:
> 
> <p>Text before ...</p>
> <ul>
>   <lh>There are lots of fruits available, e.g.:</lh>
>   <li>Apples</li>
>   <li>Pears</li>
> </ul>
> <p>More Text...</p>
> 
> Anyway I would consider it even more appropriate to allow the list 
> inside a paragraph:
> 
> <p>Text before ...</p>
> <p>There are lots of fruits available, e.g.:
>   <ul>
>     <li>Apples</li>
>     <li>Pears</li>
>   </ul>
> </p>
> <p>More Text...</p>
> 
> But I admit I have no idea what other problems this could cause.

We had this in the spec originally, but we dropped it due to a variety of 
issues (it made life harder for editors, it didn't work in text/html even 
when it looked like it did, people got confused...).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From jonas at sicking.cc  Thu Feb 12 22:28:47 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 12 Feb 2009 22:28:47 -0800
Subject: [whatwg] Methods defined for one document called after that
	document is no longer the one being displayed
In-Reply-To: <Pine.LNX.4.62.0902130315210.28232@hixie.dreamhostps.com>
References: <Pine.LNX.4.62.0808050759070.5140@hixie.dreamhostps.com>
	<278fd46c0808050133t40c3f562u25d0586fe30067f3@mail.gmail.com>
	<Pine.LNX.4.62.0808050835100.5136@hixie.dreamhostps.com>
	<Pine.LNX.4.62.0812200947130.30225@hixie.dreamhostps.com>
	<D0508AD1-F4DC-4BCE-BFD9-D07D02C7F0A0@apple.com>
	<Pine.LNX.4.62.0901311022330.14270@hixie.dreamhostps.com>
	<49851262.8060300@mit.edu>
	<Pine.LNX.4.62.0902130315210.28232@hixie.dreamhostps.com>
Message-ID: <63df84f0902122228l15893da0m5513d27a0facb90d@mail.gmail.com>

On Thu, Feb 12, 2009 at 7:15 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Sat, 31 Jan 2009, Boris Zbarsky wrote:
>>
>> Ian Hickson wrote:
>> > I haven't mentioned the 'this' behavior, so right now |this !===
>> > window|, which breaks the invariant that there is no way to actually
>> > get hold of a reference to the Window object itself (as opposed to the
>> > outer WindowProxy object that forwards to the inner Window object).
>> > This requirement would be a violation of ECMAScript 3.1, so if we
>> > could get that changed in ES3.1, that would be great. Failing that, it
>> > should probably be in the WebIDL JavaScript binding section.
>>
>> As I recall, in Gecko the keyword |this| evaluates to the outer window.
>> I'm not sure what happens to the implicit |this| that's computed when
>> defining a global function, say.
>>
>> The reason for this setup was precisely to prevent script from getting a
>> handle to the inner Window.  Since we do security checks for cross-site
>> scripting in the outer Window, any ability to pass inner Windows
>> cross-site would be an automatic security hole.
>>
>> The setup as it exists right now allows scripts that run within a single
>> window and never explicitly touch Window objects to not have to perform
>> security checks on every property access.
>>
>> You might want to double-check with Blake Kaplan, Brendan Eich, or
>> Johnny Stenback on the above, as well as on how this fits in with
>> ECMAScript 3.1.  I seem to recall something about that going by in the
>> bugs when this was being worked on, but Brendan is more likely to recall
>> the details than I am to be able to find them...
>
> I've pinged Brendan about this, but on the short term, I've put the
> requirement in HTML5, so that we don't lose it.

cc'ing a couple of people that are intimately familiar with how the
split-window implementation works in gecko.

/ Jonas


From ian at hixie.ch  Fri Feb 13 00:34:19 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Feb 2009 08:34:19 +0000 (UTC)
Subject: [whatwg] defer on style, depends
In-Reply-To: <49945130.7070703@mit.edu>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com> 
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com> 
	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com> 
	<Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com> 
	<c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>
	<49906AFA.804@mit.edu>
	<c9e12660902091056t10eba8d1i91bcb8f9bda3a528@mail.gmail.com> 
	<49908A11.6070905@mit.edu>
	<c9e12660902091815q3a659cf6q592ab7844f7b179f@mail.gmail.com>
	<4990F667.5060701@mit.edu>
	<c9e12660902112343q33aeac40i5c791ae5d81760a6@mail.gmail.com>
	<49945130.7070703@mit.edu>
Message-ID: <Pine.LNX.4.62.0902130759380.28232@hixie.dreamhostps.com>


On Mon, 9 Feb 2009, Boris Zbarsky wrote:
> Ian Hickson wrote:
> > I'm not convinced either of these are really great solutions. I think it'd
> > be better just to have the script itself only block when it hits
> > CSS-dependent APIs (though I recognise that that is a much harder problem in
> > most rendering engines today).
> 
> I'm not sure how you envision this working.  The run-to-completion 
> semantics mean that while the script is working on the API call to 
> return (which means that network events are being processed, etc), the 
> following invariants need to be maintained (list very much not 
> exhaustive):
> 
> 1)  No setTimeout timers fire.
> 2)  No XMLHttpRequest state changes happen.
> 3)  No image load events fire.
> 4)  No stylesheet load events fire (for UAs that implement such an
>     event on their <link> elements, as Gecko would like to do).
> 5)  No user interaction with the page or other pages that can reach the
>     given page is allowed.
> 
> #5 makes it unlikely that a UA would want to go this route at all.  #4 
> means that this approach would be incompatible with reasonable style 
> load events... #1, #2, #3 all mean that networking needs to 
> differentiate between the set of stylesheets we're waiting on and 
> everything else.

Yeah, fair enough.

By the way, the spec doesn't yet require the blocking behavior. I couldn't 
work out how to do it. Could you elaborate on when exactly in the process 
the style sheet is waited on? Does it happen for all scripts? For example, 
if a script inserts a style sheet and then a script, does that script wait 
for the style sheet to load?


On Mon, 9 Feb 2009, Garrett Smith wrote:
> 
> If I put the script at the bottom of the page, and a linked stylesheet 
> in the head, the script waits for the stylesheet.
> 
> I want my page to load faster and this feature prevents it.

Put the script in the <head> before the style sheet and use the "defer" 
attribute so that it runs the script as if it was at the end of the page.


> > It seems pretty simple to me; if you want the style to be loaded when 
> > the script runs, put the style first. If you don't, put the script 
> > first and defer it (or mark it async). Why should this not be enough?
> 
> The implementation might delayed the page from rendering when it sees 
> the stylesheet.

That's unrelated to scripts, though, right?

If you don't want the script to block page load, then speak to your 
browser vendor. The spec doesn't require that.


> The script's defer attribute does not work in a majority of 
> implementations. For such browsers, it makes sense to put the script 
> lower on the page for performance reasons, not before the linked 
> stylesheets. Moving the deferred script from the bottom of the page to 
> the head, just before the stylesheet would mean that those scripts would 
> load first. This would prevent the page content from loading until those 
> scripts had loaded. This would hurt performance in the majority of 
> browsers in use today.

Sure, but then the feature you describe doesn't work in today's browsers 
either, so that seems like a wash.


On Mon, 9 Feb 2009, Garrett Smith wrote:
> 
> There are two/three issues.
> 1) want to load stylesheets without having scripts block

Put the scripts first.

> 2) want to load stylesheets later, (infoPanel example)

Put the styles later.

> 3) (2), but want to make sure the stylesheet is loaded before the script runs.

Put the styles first.


> Example 1:
> <head><title></title>
> <link independent type="text/css"  ...>
> <script...></script>
> I want the browser to:
> 1) load my stylesheet and then immediately begin to load script in parallel.

Put the script first with a defer or async attribute.


> Example 2
> <head><title></title>
> <link defer type="text/css" id="lateBoundCSS" ...>
> </head>
> <body>
> ...
> <script depends="lateBoundCSS"...></script>
> </body>
> I want the browser to:
> 1) defer my linked stylesheet id="lateBoundCSS" until content is rendered
> 2) render content
> 3) upon encountering the deferred script, check the depends
> 4) upon finding Result(3) is "lateBoundCSS", wait for that resource to
> finish load before running.

I don't really think that makes sense. Why would you depend on just one 
style sheet and not the others? What if the others change the styles of 
the content you're dealing with?

You could do this, however, using a 'load' event listener on the <link> 
(though the spec doesn't yet support that -- I'm trying to reduce the 
amount of stuff I do using progress events until progress events is 
further along REC track), or, more simply, by just waiting for the 
document-wide 'load' event (though that won't wait for just the style 
sheet, it'll wait for everything).


On Mon, 9 Feb 2009, Boris Zbarsky wrote:
> 
> Not sure what this example is, or why this is insufficienty served by, 
> say, putting the <link> at the end of the HTML (assuming HTML allowed 
> that, of course).

The markup doesn't allow it but you can always do it from script.


On Mon, 9 Feb 2009, Garrett Smith wrote:
> 
> In browsers that do not support defer, the scripts must be loaded before 
> subsequent content is loaded. The scripts will block content from 
> rendering below. Scripts will also prevent download of linked 
> stylesheets that appear after in the source. This type of design would 
> also have a negative effect on browsers that do *not* support defer 
> because it means that the scripts appear first, before any linked 
> stylesheets, and cannot be included at the bottom (which is common to do 
> for performance reasons).

Right, but... so would your proposal, no?


Incidentally, you'll find that your proposals will probably get further if 
you write shorter, less argumentative, and politer e-mails.


On Thu, 12 Feb 2009, Boris Zbarsky wrote:
> 
> I'm proposing flagging scripts that don't depend on stylesheets

It seems like it is likely that such a feature would end up used before it 
works, with the result being that implementors get forced to not support 
it (a typical "race to the bottom" seen in browser implementation).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From timeless at gmail.com  Fri Feb 13 03:00:32 2009
From: timeless at gmail.com (timeless)
Date: Fri, 13 Feb 2009 13:00:32 +0200
Subject: [whatwg] Author control over media preloading/buffering
In-Reply-To: <11e306600902121455h5d38ea3n7bdebdfb2a357504@mail.gmail.com>
References: <11e306600902102020w785ea140v48e21304b96da8ef@mail.gmail.com>
	<26b395e60902120113h6b87b58dva9707d843009378e@mail.gmail.com>
	<11e306600902121455h5d38ea3n7bdebdfb2a357504@mail.gmail.com>
Message-ID: <26b395e60902130300r46eba526s168051a5317a355a@mail.gmail.com>

On Fri, Feb 13, 2009 at 12:55 AM, Robert O'Callahan
<robert at ocallahan.org> wrote:
> I don't really see a usecase for multiple priority levels. Do you have one?

i've seen a lot of places of late which have multiple videos which are
expected to play in some sort of sequence.

just saying 'autobuffer' for all of them would kill my device, but a
suggestion of which ones to buffer in order would be helpful.


From bzbarsky at MIT.EDU  Fri Feb 13 06:36:04 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Fri, 13 Feb 2009 09:36:04 -0500
Subject: [whatwg] defer on style, depends
In-Reply-To: <Pine.LNX.4.62.0902130759380.28232@hixie.dreamhostps.com>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com>
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com>
	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com>
	<Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com>
	<c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>
	<49906AFA.804@mit.edu>
	<c9e12660902091056t10eba8d1i91bcb8f9bda3a528@mail.gmail.com>
	<49908A11.6070905@mit.edu>
	<c9e12660902091815q3a659cf6q592ab7844f7b179f@mail.gmail.com>
	<4990F667.5060701@mit.edu>
	<c9e12660902112343q33aeac40i5c791ae5d81760a6@mail.gmail.com>
	<49945130.7070703@mit.edu>
	<Pine.LNX.4.62.0902130759380.28232@hixie.dreamhostps.com>
Message-ID: <49958554.2040006@mit.edu>

Ian Hickson wrote:
> By the way, the spec doesn't yet require the blocking behavior. I couldn't 
> work out how to do it. Could you elaborate on when exactly in the process 
> the style sheet is waited on? Does it happen for all scripts? For example, 
> if a script inserts a style sheet and then a script, does that script wait 
> for the style sheet to load?

The current Gecko behavior is that any stylesheet load started by 
parsing a <style> or <link> tag will increment a counter on the document 
(well, on a per-document script loader object, to be more precise). 
Completion of the load will decrement the counter.  While the counter is 
nonzero, <script> execution is blocked.  When it goes back to 0, the 
first pending script (if any) is run.  If this increments the counter 
again, no more scripts are run until the count goes to 0 again.

So it doesn't matter how the script is created/inserted, but the only 
stylesheets that block scripts are ones that the parser knows about.  So 
only the ones present in the original source or added via 
document.write.  If you createElement a <link> and insert it into the 
DOM, it won't block script execution.  Also, <link> elements pointing to 
alternate style sheets don't block script execution.

Let me know if you want more details about any part of this.

> On Thu, 12 Feb 2009, Boris Zbarsky wrote:
>> I'm proposing flagging scripts that don't depend on stylesheets
> 
> It seems like it is likely that such a feature would end up used before it 
> works, with the result being that implementors get forced to not support 
> it (a typical "race to the bottom" seen in browser implementation).

Yeah, I did mention that as an explicit worry...

-Boris



From ian at hixie.ch  Fri Feb 13 11:16:44 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Feb 2009 19:16:44 +0000 (UTC)
Subject: [whatwg] defer on style, depends
In-Reply-To: <49958554.2040006@mit.edu>
References: <c9e12660902082115p12181f54qe6b02b91cb45e509@mail.gmail.com> 
	<Pine.LNX.4.62.0902090518502.952@hixie.dreamhostps.com> 
	<c9e12660902090025v19b3aacct88882cf0bd183527@mail.gmail.com> 
	<Pine.LNX.4.62.0902091022330.952@hixie.dreamhostps.com> 
	<c9e12660902090935k2cd36d88k489812b45dded857@mail.gmail.com>
	<49906AFA.804@mit.edu>
	<c9e12660902091056t10eba8d1i91bcb8f9bda3a528@mail.gmail.com> 
	<49908A11.6070905@mit.edu>
	<c9e12660902091815q3a659cf6q592ab7844f7b179f@mail.gmail.com>
	<4990F667.5060701@mit.edu>
	<c9e12660902112343q33aeac40i5c791ae5d81760a6@mail.gmail.com>
	<49945130.7070703@mit.edu>
	<Pine.LNX.4.62.0902130759380.28232@hixie.dreamhostps.com>
	<49958554.2040006@mit.edu>
Message-ID: <Pine.LNX.4.62.0902131915190.952@hixie.dreamhostps.com>

On Fri, 13 Feb 2009, Boris Zbarsky wrote:
> 
> The current Gecko behavior is that any stylesheet load started by parsing a
> <style> or <link> tag will increment a counter on the document (well, on a
> per-document script loader object, to be more precise). Completion of the load
> will decrement the counter.  While the counter is nonzero, <script> execution
> is blocked.  When it goes back to 0, the first pending script (if any) is run.
> If this increments the counter again, no more scripts are run until the count
> goes to 0 again.
> 
> So it doesn't matter how the script is created/inserted, but the only
> stylesheets that block scripts are ones that the parser knows about.  So only
> the ones present in the original source or added via document.write.  If you
> createElement a <link> and insert it into the DOM, it won't block script
> execution.  Also, <link> elements pointing to alternate style sheets don't
> block script execution.

So in this:

   <!DOCTYPE html>
   ...
   <script>
    document.write('<link rel=stylesheet href=style>');
    document.write('<script>a();<\/script>');
    b();
   </script>

...is the script paused after the second document.write() call, before a() 
and b() execute?

(When replying please leave your text above in the reply, so that I don't 
lose context -- thanks!)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Fri Feb 13 11:45:27 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Feb 2009 19:45:27 +0000 (UTC)
Subject: [whatwg] Color attributes
In-Reply-To: <op.uo58doqpidj3kv@zcorpandell.linkoping.osa>
References: <op.tu0hbhll7a8kvn@hp-a0a83fcd39d2>
	<op.ui38bralidj3kv@zcorpandell.linkoping.osa>
	<Pine.LNX.4.62.0902110022310.28232@hixie.dreamhostps.com>
	<op.uo58doqpidj3kv@zcorpandell.linkoping.osa>
Message-ID: <Pine.LNX.4.62.0902131945220.28232@hixie.dreamhostps.com>

On Wed, 11 Feb 2009, Simon Pieters wrote:
> On Wed, 11 Feb 2009 01:22:59 +0100, Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 16 Oct 2008, Simon Pieters wrote:
> > > 
> > > Color attributes in HTML have special processing. [...]
> > > 
> > > It seems that some pages use three-digit notation and expect it to 
> > > work as in CSS. I've made the algorithm do that and I've drafted up 
> > > a spec for this:
> > > 
> > >    http://simon.html5.org/specs/html-color-attributes
> > 
> > The spec now defines this.
> 
> It seems the spec lacks the CSS2 system colors and 'transparent'.

Fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Fri Feb 13 12:03:53 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 13 Feb 2009 20:03:53 +0000 (UTC)
Subject: [whatwg] Styling of area elements (as displayed
 within	referencing image)
In-Reply-To: <20090211193625.GA1929@pickering.dbaron.org>
References: <20070510182121.GA4117@ridley.dbaron.org>
	<Pine.LNX.4.62.0902110838000.28232@hixie.dreamhostps.com>
	<20090211193625.GA1929@pickering.dbaron.org>
Message-ID: <Pine.LNX.4.62.0902132001440.28232@hixie.dreamhostps.com>

On Wed, 11 Feb 2009, L. David Baron wrote:
> >
> >    http://www.whatwg.org/specs/web-apps/current-work/#image-maps-0
> 
> That text seems ambiguous in the case of values like 'cursor:
> inherit' on area elements (and the possibility of future values that
> also take values from the parent element).  In particular, the text:
>   # has a value explicitly specified (as opposed to inheriting it
>   # from the element's parent)
> seems self-contradictory regarding 'cursor: inherit'.

I've reworked this to use another approach that should make more sense. 
Let me know if it still has pr