On 03/02/2008 03:02 PM, Ian Hickson wrote:
On Tue, 31 Jul 2007, Philip Taylor wrote:
IE undocumentedly recognises some which nobody else does:
aafsU+206D ACTIVATE ARABIC FORM SHAPING
ass U+206B ACTIVATE SYMMETRIC SWAPPING
iafsU+206C INHIBIT ARABIC FORM SHAPING
iss U+206A
On Thu, 18 Mar 2010, Simon Pieters wrote:
On Thu, 18 Mar 2010 01:03:33 +0100, Ian Hickson i...@hixie.ch wrote:
On Mon, 22 Feb 2010, Kornel Lesi�~Dski wrote:
I'm wondering if data-* attributes should be renamed to priv-* to
make it clearer that it's page's _private_ data.
data-
On Thu, 18 Mar 2010, Alex Bishop wrote:
In the processing model for image maps (section 4.8.13.2), step 8 of the
processing instructions for area elements says that if the shape
attribute is in the Circle state:
Let x be the first number in coords, y be the second number, and r be
the
On Thu, Sep 3, 2009 at 7:41 AM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 31 Aug 2009, Jonas Sicking wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
'yield' usually refers to halting execution. I would expect the above
name to stop the
On Mon, 31 Aug 2009, Jonas Sicking wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
'yield' usually refers to halting execution. I would expect the above
name to stop the current thread and allow other threads to run. While
that is what
On Tue, 7 Apr 2009, Jeff Creamer wrote:
Hi. Since March of '06, Opera 9 has supported a custom extension to the
canvas context called opera-2dgame. Importantly, their extension adds
these methods:
getPixel(x, y)
Returns the pixel value (colour, opacity) at (x, y). Returned in the
form
The ImageData APIs already provide the ability to do this and are
already supported by Firefox, Opera and Safari.
Given the ImageData APIs, and given that they are generally more efficient
at the typical use cases for getPixel/setPixel, I haven't added getPixel/
setPixel to the spec.
Cheers,
On Fri, 6 Mar 2009, Rikkert Koppes wrote:
The example presented at the section element definition [1]. The given
markup could be ok, however, with a look at the actual contents (a nice
essay about apples), the h1 elements found in the section elements
should actually be h2 elements, giving
On Mon, 25 Feb 2008, Maciej Stachowiak wrote:
On Feb 25, 2008, at 2:42 PM, Ian Hickson wrote:
label
This would preclude any sane way of putting form controls in
legends, which would be bad.
This can't be fixed in the spec.
Is the ability to put form controls in
On Tue, 26 Feb 2008, Tab Atkins Jr. wrote:
- LH (caption for list! A must-have)
Why not using the title attribute?
Actually with figure the lh element is now better handled using
figure and legend.
Using figure and legend:
On Mon, 24 Mar 2008, Tab Atkins Jr. wrote:
TH and TD
* abbr (I think that's supported by screen readers, but need to verify)
I don't really see that these attributes actually help anyone.
I don't have a screen reader to verify, but afaik abbr= is used to provide a
shortened form of
On Thu, 21 Aug 2008, Pawe�~B Stradomski wrote:
I guess it's to difficult to implement such guessing right.
thead
tr
th abbr=EuropeAmount sold in Europe/th
th abbr=AsiaAmount sold in Asia/th
th abbr=North AmericaAmount sold in North America/th
..
/tr
/thead
This
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Thursday, August 21, 2008 11:16 AM
To: Tab Atkins Jr.
Cc: whatwg List
Subject: Re: [whatwg] several messages about tables and related subjects
On Mon, 24 Mar 2008, Tab Atkins Jr. wrote:
TH
On Thu, 12 Jun 2008, Jorge Bay Gondra wrote:
I was trying to imaging how it would be to build a site, and I realized
that, in the case of site with 2 nav bars (typically 2 sidebars) there's
not a way to specify which is the main sidebar and which is
accessory... What do you think about
On Tue, 20 Mar 2007, Nicholas Shanks wrote:
I asked for the resurrection of HTML+'s imagefallback/image element
last month. The reasons I cited were exactly the same as the reasons
being given now in favour of the video element, however I was told
(paraphrasing) Why bother, you can just
On Tue, 13 Mar 2007, L. David Baron wrote:
The wording of the value of href for base elements [1] is not quite the
same as the wording for anchor elements [2], and technically [3] that
wording allows only absolute URIs. They should probably both say they
allow URI references (or IRI
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: Friday, June 06, 2008 2:12 AM
To: [EMAIL PROTECTED]
Subject: Re: [whatwg] several messages
On Sun, 17 Jul 2005, Dean Edwards wrote:
I'll add another case: the onafterprint event could be used
On Sun, 17 Jul 2005, Dean Edwards wrote:
Anne van Kesteren wrote:
Shouldn't the print method on the window DOM interface be defined as well?
Example: button onclick=window.print()print/button
IE has some nice onbeforeprint/onafterprint events. Can we add these
too?
Defined both.
On Tue, 4 Mar 2008, �istein E. Andersen wrote:
On Fri, 29 Feb 2008 01:21:20 + (UTC), Ian Hickson wrote:
(I've made the characters not allowed in XML also not allowed in HTML,
with the exception of some of the space characters which we need to
have allowed for legacy reasons.)
The
On Tue, 15 Apr 2008, Shannon wrote:
All of them. class isn't intended for styling, it's intended to
subclass elements.
Regardless of the intention of the class element it is NOT used in the
real world to subclass anything but styles and custom script. We may
wish otherwise but that is
Ironically (given that you proposed using rel= instead) as far as I know
Google has never based anything on class values, but has used rel=
values (like rel=nofollow).
Which indicates to me that they were concerned enough about
class=nofollow to not use it. I personally think that nofollow
Ian Hickson wrote:
On Tue, 24 Apr 2007, Elliotte Harold wrote:
It occurs to me that one of the most frequently used nits of
pseudo-markup is to indicate sarcasm. For example,
sarcasmYeah, George W. Bush has been such a great president./sarcasm
Should we perhaps formalize this? Is there any
On Tue, 15 Apr 2008, Shannon wrote:
It's alternative because it attempts to actually classify something
rather than generically label it. I agree that class should only do the
first and I do this with my own code but most designers do not. As far
as the web design world is concerned class
Ian Hickson wrote:
We're not talking about making class meaningful. I'm not sure I understand
what you are arguing against at this point.
The proposal is just that authors should use class= to distinguish the
various ways they use i so that they can (e.g.) style them differently.
Where is
On Wed, 16 Apr 2008, Shannon wrote:
Ian Hickson wrote:
We're not talking about making class meaningful. I'm not sure I
understand what you are arguing against at this point.
The proposal is just that authors should use class= to distinguish
the various ways they use i so that they
I seemed to have missed these when going through the cite e-mails
recently.
On Sat, 16 Apr 2005, John Lewis wrote:
A way to mark up titles is something I've always wanted in HTML.
Currently, cite is only appropriate for actual citations. I rarely
cite books, movies, etc.; I'm usually just
If we go with something like a TYPE attribute, I hope we can give it a
better name. However, hiding semantics inside the value of an
attribute is a poor markup design in humble opinion. (Although it also
has some advantages.)
It's subclassing: the general is sufficient, the specific
On Tue, 15 Apr 2008, Shannon wrote:
I've seen a few suggestions now that class be used as an identifying
attribute for purposes other than CSS. While this seems logical it
raises some issues for designers and implementers. Consider the
following:
cite class=small book blueThe
All of them. class isn't intended for styling, it's intended to subclass
elements.
Regardless of the intention of the class element it is NOT used in the
real world to subclass anything but styles and custom script. We may
wish otherwise but that is irrelevant. The value of class to me is:
On Tue, 24 Apr 2007, Elliotte Harold wrote:
It occurs to me that one of the most frequently used nits of
pseudo-markup is to indicate sarcasm. For example,
sarcasmYeah, George W. Bush has been such a great president./sarcasm
Should we perhaps formalize this? Is there any benefit to be
On Sun, 14 Nov 2004, Anne van Kesteren wrote:
I was wondering if the WHATWG is going to redefine how NOSCRIPT[1]
works, since the current specification of it is quite difficult to
implement. Besides, I don't think it ever was implemented properly.
Also, brought to my attention by
Ian Hickson wrote:
Summary: I've made the spec require that any punctuation for q be
included inside the element; I've added examples for q.
...
How would you define CSS pseudo-elements for open and close quotes in
such a way that they would be implementable and would not match
apostrophes
Summary: I've made the spec require that any punctuation for q be
included inside the element; I've added examples for q.
On Wed, 10 Nov 2004, Thomas Scholz wrote:
Ian Hickson schrieb:
I sometimes want to take quotes and put them into floats with huge
oversized quotemarks under the text
The HTMLWG's ISSUE-31 is Should img without alt ever be conforming.
It isn't clear from this issue what exactly the problem with the current
spec text is. The current text in the spec requires alt= in all cases
except when the page is generated in a manner where alternative text is
not
Ian Hickson (2008-03-23):
On Tue, 18 Mar 2008, Christoph Päper wrote:
a spanvalid non-negative integer/span greater than zero.
Isn't that the description of a valid positive integer? If that
term is
not used or defined yet, why not?
Because positive is confusing to people. Some people
Dnia 23-03-2008, N o godzinie 19:29 +, Ian Hickson pisze:
Executive summary:
* header/id is in.
* summary= is not in.
* axis= is not in.
* the automatic header association algorithm has been expanded.
* a number of minor fixes and editorial edits were made.
For details, see
TH and TD
* abbr (I think that's supported by screen readers, but need to verify)
I don't really see that these attributes actually help anyone.
I don't have a screen reader to verify, but afaik abbr= is used to provide a
shortened form of the header when it is spoken aloud repeatedly.
On Tue, 18 Mar 2008, Christoph P�per wrote:
+ h4Attributes common to codetd/code and codeth/code
elements/h4
+ pThe codetd/code and codeth/code elements may have a dfn
+ title=attr-tdth-colspancodecolspan/code/dfn content
+ attribute specified, whose value must be a spanvalid
On 23/03/2008, Ian Hickson [EMAIL PROTECTED] wrote:
Isn't that the description of a valid positive integer? If that term is
not used or defined yet, why not?
Because positive is confusing to people. Some people (including me)
think that 0 is positive.
I'm fairly sure that there are
On Sun, 23 Mar 2008, Paul Waring wrote:
On 23/03/2008, Ian Hickson [EMAIL PROTECTED] wrote:
Isn't that the description of a valid positive integer? If that term is
not used or defined yet, why not?
Because positive is confusing to people. Some people (including me)
think that 0 is
Dnia 03-03-2008, Pn o godzinie 20:18 +, David Gerard pisze:
On 03/03/2008, Ian Hickson [EMAIL PROTECTED] wrote:
On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote:
When I want to define a paragraph-style tool-tip, I am left with the
following choice: either make the source code
Executive summary:
Hoo boy did these e-mails end up with a lot of complicated changes -- a
total of 38 different checkins. Some were editorial, but others were quite
invasive changes. Here are the main ones:
* Merged insertion modes and phases. Theoretically this didn't change
anything
Dnia 02-03-2008, N o godzinie 23:02 +, Ian Hickson pisze:
On Tue, 31 Jul 2007, Simon Pieters wrote:
Aha. I didn't think of testing attributes.
Safari preserves CRs in attribute values, both real and NCRs. CRLF
pairs, LFCR pairs, CRs and LFs cause a single linebreak in the
On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote:
When I want to define a paragraph-style tool-tip, I am left with the
following choice: either make the source code unreadable by making an
excessively long line (this is also true for URI attributes but they are
not expected to be readable)
On 03/03/2008, Ian Hickson [EMAIL PROTECTED] wrote:
On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote:
When I want to define a paragraph-style tool-tip, I am left with the
following choice: either make the source code unreadable by making an
excessively long line (this is also true for
David Gerard wrote:
On 03/03/2008, Ian Hickson [EMAIL PROTECTED] wrote:
On Mon, 3 Mar 2008, Krzysztof Żelechowski wrote:
When I want to define a paragraph-style tool-tip, I am left with the
following choice: either make the source code unreadable by making an
excessively long line
On Sun, 2 Mar 2008 23:02:07 + (UTC), Ian Hickson wrote:
On Sat, 15 Sep 2007, Henri Sivonen wrote:
Currently, unquoted attributes may start with a =
[as in img alt==Foobar src='404']
This means that the notion of conformance fails to catch what is most
likely an error: [...]
To
On Fri, 29 Feb 2008 01:21:20 + (UTC), Ian Hickson wrote:
(I've made the characters not allowed in XML also not allowed in HTML,
with the exception of some of the space characters which we need to have
allowed for legacy reasons.)
The C1 character U+0085 NEXT LINE (NEL) is also a Unicode
Executive summary:
* Changed the rang; and lang; entities (which we'd already changed
anyway) to something more appropriate. (r1286)
* Made a number of things parse errors to allow conformance checkers to
catch common attribute mistakes. (r1292, r1293, r1299, r1303)
* Made a number
Dnia 29-02-2008, Pt o godzinie 01:21 +, Ian Hickson pisze:
In 8.2.2.4, I have no idea what's the reason or purpose of point 1,
which reads If the new encoding is UTF-16, change it to UTF-8.. I
suspect some misunderstanding.
This is required because many pages are labelled as
On 29 Feb 2008, at 16:33, Julian Reschke wrote:
Geoffrey Sneddon wrote:
It seems like the HTTP spec should define how to handle that, but
the HTTP working group has indicated a desire to not specify
error handling behaviour, so I guess it's up to us.
IE and Safari use the first one,
Geoffrey Sneddon wrote:
Content-Type: XML
Content-Type: text/XML
Using the first would break badly. I guess it seems to work because of
content-type sniffing on an unknown (and invalid) header
Or because the header parser uses the first header that actually looks like a
valid content-type
On 29 Feb 2008, at 01:21, Ian Hickson wrote:
- Again there, shouldn't we be given unicode codepoints for that (as
it'll be a unicode string)?
Not sure what you mean.
This is just me being incredibly dumb. Ignore it.
On Sat, 26 May 2007, Henri Sivonen wrote:
The draft says:
A
Dnia 27-02-2008, Śr o godzinie 08:06 -0500, Michel Fortin pisze:
Now, suppose you have this:
pA header looks like this in your browser:/p
h1Some text!/h1
... unfortunately, the h1 here isn't a real header in the document:
it's an illustration of a header (ah-ha: figure!)
Executive summary: I did most of the changes suggested below.
On Wed, 15 Aug 2007, Simon Pieters wrote:
The spec says:
Other nodes types (e.g. Attr) cannot occur as children of elements. If
they do, this algorithm must raise an INVALID_STATE_ERR exception.
s/elements/elements or
Le 2008-02-25 à 17:42, Ian Hickson a écrit :
On Mon, 16 Jul 2007, Michel Fortin wrote:
Since I'm not convinced that the current content model for figure
is
adequate [1], I decided to dig more examples where figures in HTML
pages
would be hard to fit with the current model. Here are the
Le 2008-02-27 à 2:17, Ian Hickson a écrit :
On Thu, 6 Apr 2006, Michel Fortin wrote:
Le 6 avr. 2006 à 6:44, Alexey Feldgendler a écrit :
This heading shouldn't be within the document's main tree of
headings.
It should be completely taken out, that's what aside means. But it
can't be done
On Wed, 27 Feb 2008, Michel Fortin wrote:
I'm wondering however about the definition leaving something out. It
says: The figure element represents some prose content, optionally with
a caption, which can be moved away from the main flow of the document
without affecting the document's
On Tue, 26 Feb 2008 06:16:15 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Feb 25, 2008, at 2:42 PM, Ian Hickson wrote:
label
This would preclude any sane way of putting form controls in
legends, which would be bad.
This can't be fixed in the spec.
Is the ability
On Mon, Feb 25, 2008 at 10:29 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 8 Feb 2007, Jorgen Horstink wrote:
On Feb 8, 2007, at 9:00 PM, David Latapie wrote:
On Thu, 8 Feb 2007 19:17:32 +, Nicholas Shanks wrote:
On 6 Feb 2007, at 07:57, Karl Dubost wrote:
This e-mail is a reply to all the pending feedback related to lists in
HTML5. It covers an array of subjects and contains replies to e-mails from
around forty different people, all of whom are bcc'ed, across two mailing
lists. When replying please select a single mailing list to reply to, and
On Feb 25, 2008, at 2:42 PM, Ian Hickson wrote:
label
This would preclude any sane way of putting form controls in
legends, which would be bad.
This can't be fixed in the spec.
Is the ability to put form controls in figure captions (let alone more
than one form control)
Sorry about the three-way cross-post, but this message contains replies to
e-mails from those three mailing lists. Please select just the one mailing
list when replying, and trim the quotes below to include only what you are
discussing. Thanks.
Executive summary:
* Made it possible to
Ian Hickson:
On Wed, 8 Jun 2005, Christoph Päper wrote:
Ian Hickson:
On Mon, 23 May 2005, Christoph Päper wrote:
I almost didn't remember I was so vigorously against |hr|.
Everything inside a 'div' belongs together somehow and everything
that shares a class (...) is related to each other
Executive summary: I made it that if address applies to the body element
it really applies to the whole document. I did not make address suitable
for all contact information; it continues to be limited to contact
information for the current section/article/page. I couldn't see a
convincing
Executive summary: no changes made; not much controversy.
On Sat, 21 May 2005, Rimantas Liubertas wrote:
On 5/21/05, Ian Hickson [EMAIL PROTECTED] wrote:
...
Actually Steven Pemberton gave some interesting examples of what look
to me like valid use cases for hr/ in a recent talk of his.
On Fri, 18 Jan 2008, Philip Taylor wrote:
Maybe the desired properties are:
- drawImage(img) onto a displayed canvas should look the same as
the original img, regardless of whether the image has gamma etc.
- toDataURL should return the same raw pixel data as getImageData, at
least for
On Wed, 12 Dec 2007, alex wrote:
We have to take into accounts the needs of everyone. This includes
large companies. If large companies will only accept codecs that
they've already implemented, then that may have to be one of the
criteria.
This conflicts with:
Whatever solution
Ian Hickson wrote:
Ogg isn't a choice, unfortunately. I agree that little choice remains,
though. But this is an open issue, and experts in the field are actively
trying to resolve it to everyone's satisfaction.
Yes, Ogg most certainly is a choice. Every time you deny this, you give
more
Ian Hickson wrote:
At least with Theora we can avoid any known ones. All codecs have a
risk of submarine patents (though with extensive having been done for
Theora, at least that risk is lowered, if not eliminated completely), so
that argument is a wash, its on both sides of the equation,
On Wed, 12 Dec 2007, Jeff McAdams wrote:
Ian Hickson wrote:
Ogg isn't a choice, unfortunately. I agree that little choice remains,
though. But this is an open issue, and experts in the field are
actively trying to resolve it to everyone's satisfaction.
Yes, Ogg most certainly is a
On Wed, 12 Dec 2007, Jeff McAdams wrote:
And this is exactly the way that Apple, Nokia, et al are hijacking this
process. They throw out some nebulous business reason for why they
don't want to use Ogg et al, and it gets bought, hook line and sinker.
Maybe there is some legitimacy to
Ian Hickson schrieb:
Ogg Theora has not had an exhaustive patent search (you may be thinking of
Ogg Vorbis). In fact, it is likely the case that H.264 has had a _more_
exhaustive patent search than Ogg Theora.
Well, thanks to VP3 having been a commercial product licensed to
numerous
Ian, are you saying that not implementing a SHOULD statement in the spec
would make a browser non-compliant with HTML5?
Are you saying that if a vendor does not implement the OPTIONAL Ogg
support then they would not use HTML5 at all?
I'm not being sarcastic here. I'd actually like you to
(I've been watching the emails fly around with great interest, but there has
been a rather significant volume. You'll have to forgive me if the following
question has already been answered.)
It seems to me that the argument keeps coming back to the fact that H.264/AAC
has patent protection
Pfeiffer
Sent: 12 December, 2007 08:24
To: Dave Singer
Cc: WHATWG Proposals
Subject: Re: [whatwg] several messages regarding Ogg in HTML5
On Dec 12, 2007 11:38 AM, Dave Singer [EMAIL PROTECTED] wrote:
Possible action:
The members of the WG are engineers, not IPR experts. There
is general
Dnia 11-12-2007, Wt o godzinie 18:21 -0500, Manuel Amador (Rudd-O)
pisze:
That's no reason to NOT SUGGEST Ogg Vorbis / Theora. No one here is saying
that HTML5 should forbid proprietary codecs -- all we're claiming for is the
judicious and well-deserved mention of two free technologies in
Dnia 11-12-2007, Wt o godzinie 23:20 +0100, alex pisze:
First, I would like to thank you for the feedback, and I must admit it
is a rather sensitive situation, more so then I imagined at first. But
because of the nature of submarine patents, I don't quite see how you
can actually find a
I think you meant Vorbis, but other than a quick sed s/Theora/Vorbis/g, I see
myself agreeing with you.
El Mar 11 Dic 2007, Jeff McAdams escribió:
Ian Hickson wrote:
On Tue, 11 Dec 2007, Maik Merten wrote:
If keeping the web free of IP licensing horrors and being interoperable
with as
At 23:20 +0100 11/12/07, alex wrote:
I have seen this argument pop up now and again, but I have failed to
actually find the URL to this, could someone post it please?
Hi. It was a record of a discussion at the HTML WG meeting, but
since I wrote it, I guess I can re-post it here (and it
At 17:30 -0500 11/12/07, Jeff McAdams wrote:
Apple and Nokia's stated reasons for objecting to Theora are crap...
I can't speak for Nokia. But you are mis-characterizing Apple. We
have expressed concern, and suggested that perhaps someone who can be
seen to be independent, and is
Dave Singer wrote:
At 17:30 -0500 11/12/07, Jeff McAdams wrote:
Apple and Nokia's stated reasons for objecting to Theora are crap...
I can't speak for Nokia. But you are mis-characterizing Apple. We have
expressed concern, and suggested that perhaps someone who can be seen to
be
I've tried to pick a representative sample of the e-mails sent since my
last e-mail. The ones I didn't reply to have been saved to the outstanding
video codec feedback folder, and I'll reply to them once we have a real
solution to the problem of finding a common codec.
At 2:19 + 12/12/07, Ian Hickson wrote:
I would much rather Apple not implement HTML5 at all, so I can call
Apple out on it in the marketplace, than to let an encumbered technology
be ensconced in a standard like HTML5.
I entirely agree that it would be unacceptable for HTML5 to
On Dec 11, 2007 7:47 PM, Dave Singer [EMAIL PROTECTED] wrote:
I am sure there are many other questions...
One question might concern the value in standardizing a shell API for
proprietary codecs. If there are no freely implementable solutions,
maybe the spec should drop it.
Personally, I think
On Dec 12, 2007 11:38 AM, Dave Singer [EMAIL PROTECTED] wrote:
Possible action:
The members of the WG are engineers, not IPR experts. There is
general consensus that a solution is desirable, but also that
engineers are not well placed to find it:
a) they are not experts in the IPR and
On Tue, 6 Nov 2007, Geoffrey Sneddon wrote:
I think it's way better to stay consistent. Especially as the feature
affects the Referer (sic) header.
I too think Anne is right here � there are enough things that are
inconsistent in the web already. Don't add another thing that requires
On 4 Nov 2007, at 12:40, Anne van Kesteren wrote:
On Sat, 03 Nov 2007 18:27:50 +0100, Krzysztof ??elechowski [EMAIL PROTECTED]
wrote:
Dnia 03-11-2007, sob o godzinie 08:42 +, Ian Hickson napisa??(a):
Ok, I've added a rel value similar to nofollow called
noreferer that
does this.
While we are unable correct the spelling of referer, we certainly
need not duplicate it for noreferrer. There must be some end to
this self-humiliation.
I think it's way better to stay consistent. Especially as the
feature affects the Referer (sic) header.
I too think Anne is right
While we are unable correct the spelling of referer, we
certainly need not duplicate it for noreferrer. There must be
some end to this self-humiliation.
I think it's way better to stay consistent. Especially as the
feature affects the Referer (sic) header.
I too think Anne is right
On Sat, 3 Nov 2007, Krzysztof Żelechowski wrote:
Ok, I've added a rel value similar to nofollow called noreferer
that does this.
While we are unable correct the spelling of referer, we certainly need
not duplicate it for noreferrer. There must be some end to this
self-humiliation.
On Sat, 03 Nov 2007 18:27:50 +0100, Krzysztof Żelechowski
[EMAIL PROTECTED] wrote:
Dnia 03-11-2007, sob o godzinie 08:42 +, Ian Hickson napisał(a):
Ok, I've added a rel value similar to nofollow called noreferer that
does this.
While we are unable correct the spelling of referer, we
On 10/26/07, Ian Hickson [EMAIL PROTECTED] wrote:
Bikeshed alert.
On Fri, 19 Oct 2007, Michael A. Puls II wrote:
Now, I am suggesting:
currentLoop - playIndex || currentPlayIndex || currentPlayCountIndex
I have left this one for now. I don't like index, for reasons discussed
below.
I
Bikeshed alert.
On Fri, 19 Oct 2007, Michael A. Puls II wrote:
Maybe we should rename 'loopcount' to 'playcount'...?
playcount fits better with the number of times to play the clip than
loopcount does.
Ok. Done.
Hmm. Is the spec really ambigious?
Here's an example: [...]
What
On Fri, 8 Jun 2007, Dave Singer wrote:
Proposal: user settings that correspond to a accessibility needs. For
each need, the user can choose among the following three dispositions:
* favor (want): I prefer media that is adapted for this kind of
accessibility.
* disfavor (don't want):
On Fri, 5 Oct 2007, Brady Eidson wrote:
I think `bool changeVersion()` has a deficient design, and the content
of its description - combined with the lack of clarity around active
and open transactions - makes implementing it even more dubious.
First off, it is synchronous.
Fixed.
But
On Oct 17, 2007, at 12:47 AM, Ian Hickson wrote:
But I also have some confusion about the actual intention of the
method.
The line that is the source of most confusion - When the method is
invoked, the user agent must obtain a full lock of the database
(waiting
for all open transactions
On Fri, 12 Oct 2007, Anne van Kesteren wrote:
I think there should be an error code for the database being full. For
some platforms there's not much storage space available and knowing
whether or not there's some space left is useful. So you can decide to
only store the critical data for
On Mon, 2 Jul 2007, Robert Sayre wrote:
Basically, I think offline caches should respect the Vary: HTTP header,
and maybe more. Applications will need to do this right anyway, if they
want to function correctly in the presence of ISP HTTP proxies (AOL,
TMobile, etc), corporate firewalls,
On Wed, 19 Sep 2007, Maciej Stachowiak wrote:
Here are my thoughts on the problem of bugzilla and similar applications
with open-ended URI spaces.
1) It doesn't fit well with the URI model to treat the query part of the
URI specially. First, it's not in line with the web architecture
1 - 100 of 248 matches
Mail list logo
